From noreply at sourceforge.net Wed Sep 1 00:30:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 00:31:00 2004 Subject: [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 16:04 Message generated for change (Comment added) made by hakansonsf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-31 15:30 Message: Logged In: YES user_id=1103758 Sorry, that was not helpful: I meant test TIOCGPGRP on a pseudo-tty that the testing process creates. Another alternative would be to test some STREAMS ioctl against a stream/pipe that the process creates. But yes, this quickly gets complicated. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-16 11:08 Message: Logged In: YES user_id=1103758 Maybe test TIOCGPGRP on a file/directory that the test creates anew, instead of /dev/tty. That should definitely match the process group of the current process. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-14 06:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-13 15:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-05 03:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 08:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 04:21 Message: Logged In: YES user_id=6656 Oh good <wink> Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 09:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 03:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply at sourceforge.net Wed Sep 1 15:32:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 15:33:31 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 09:32 Message: Logged In: YES user_id=11375 'e = r+w' means 'e' can contain the same descriptor twice, if it's both readable and writable, and I think this matters. Duplicate fd's don't cause a problem with the select() system call itself, but the return value from select.select() would include the file descriptor twice. (I've attached a test program that demonstrates this for readable fds.) Therefore, I think the 'if is_r or is_w' logic is necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:49 Message: Logged In: YES user_id=31435 Logic similar to the logic in the patch worked for me when I tried it. Suggest it would be faster and clearer to just add e = r + w to the 2.3 asyncore poll(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 12:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Wed Sep 1 16:08:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 16:09:01 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 10:08 Message: Logged In: YES user_id=11375 Original patch committed as rev. 1.61 of asyncore.py. I'm leaving the bug open until Tim (or someone) reports that the problem is fixed. poll2 (the one that uses select.poll()) should automatically remove objects for which POLLNVAL is set -- that's what the error means, after all. I'll worry about that after 2.3alpha3 is released. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 09:32 Message: Logged In: YES user_id=11375 'e = r+w' means 'e' can contain the same descriptor twice, if it's both readable and writable, and I think this matters. Duplicate fd's don't cause a problem with the select() system call itself, but the return value from select.select() would include the file descriptor twice. (I've attached a test program that demonstrates this for readable fds.) Therefore, I think the 'if is_r or is_w' logic is necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:49 Message: Logged In: YES user_id=31435 Logic similar to the logic in the patch worked for me when I tried it. Suggest it would be faster and clearer to just add e = r + w to the 2.3 asyncore poll(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 12:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Wed Sep 1 17:13:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 17:13:31 2004 Subject: [ python-Bugs-990911 ] Crash from Rapid Clicks Message-ID: Bugs item #990911, was opened at 2004-07-14 09:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Karl (thedisciple) Assigned to: Kurt B. Kaiser (kbk) Summary: Crash from Rapid Clicks Initial Comment: IDLE crashes when I rapidly (within 1/2 second, maybe) click the Run, then Options menus on the menu bar. These seem to be the only menus for which the crash happens, which is odd. I'm running Windows XP SP1 on an AMD system using Python 2.3.3 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-09-01 10:13 Message: Logged In: YES user_id=149084 No response from OP, closing as works-for-me. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:52 Message: Logged In: YES user_id=149084 I can't duplicate this on W2K using 2.3.4 or 2.4a1. Please try 2.4a2 when it comes out and if this issue is still there please provide the code which was running and whether you used F5 or the menu to start the run. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 20:46 Message: Logged In: YES user_id=33168 Kurt, have you heard of this before? ---------------------------------------------------------------------- Comment By: Karl (thedisciple) Date: 2004-07-14 11:04 Message: Logged In: YES user_id=1083575 Update: With a little more expirimentation I found that it often crashes whenever any of the last 3 menus (Options, Windows, Help) are clicked. It works fine if another menu is clicked then the mouse is moved over one of the last three menus to open it. I also noticed that after crashing the program many times to determine the problem, I see about twenty pythonw.exe processes running in Windows Task Manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470 From noreply at sourceforge.net Wed Sep 1 18:41:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 18:41:11 2004 Subject: [ python-Bugs-1020540 ] a wrong link from "frame object" in lib index Message-ID: Bugs item #1020540, was opened at 2004-09-01 09:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020540&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: a wrong link from "frame object" in lib index Initial Comment: a "frame object" link (in the library index: http://www.python.org/doc/current/lib/genindex.html) leads to "7.1 signal -- Set handlers for asynchronous events" page which seems wrong ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020540&group_id=5470 From noreply at sourceforge.net Wed Sep 1 20:10:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 20:10:11 2004 Subject: [ python-Bugs-1020605 ] senddigest error Message-ID: Bugs item #1020605, was opened at 2004-09-01 14:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020605&group_id=5470 Category: None Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: James O'Kane (jo2y) Assigned to: Nobody/Anonymous (nobody) Summary: senddigest error Initial Comment: I am having the same error as mentioned in this post: http://mail.python.org/pipermail/mailman-developers/2004-June/016931.html My traceback: Aug 30 16:52:38 2004 (14988) Traceback (most recent call last): File "/usr/opt/mailman//Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/opt/mailman//Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/opt/mailman//Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/opt/mailman//Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 82, in process send_digests(mlist, mboxfp) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/opt/mailman//Mailman/Handlers/Scrubber.py", line 257, in process url = save_attachment(mlist, part, dir) File "/usr/opt/mailman//Mailman/Handlers/Scrubber.py", line 348, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/opt/mailman//pythonlib/email/Message.py", line 683, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/opt/mailman//pythonlib/email/Message.py", line 566, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/opt/mailman//pythonlib/email/Message.py", line 516, in _get_params_preserve params = Utils.decode_params(params) File "/usr/opt/mailman//pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/opt/mailman//pythonlib/email/Utils.py", line 283, in decode_rfc2231 charset, language, s = s.split("'", 2) ValueError: unpack list of wrong size s at this point has the value: NET News.com.pdf What I think are the relavent headers: X-Mailer: Apple Mail (2.619) --Apple-Mail-7--372163126 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644;CNET News.com.pdf" Content-Disposition: inline;silicon | C"; filename*1="NET News.com.pdf" If you need more information than this, I'll need to run it past the sender of the message, first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020605&group_id=5470 From noreply at sourceforge.net Wed Sep 1 21:09:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 21:09:59 2004 Subject: [ python-Bugs-1017978 ] IDLE DOES NOT START ON WinXP Pro Message-ID: Bugs item #1017978, was opened at 2004-08-27 17:23 Message generated for change (Comment added) made by gj_carman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Snake (gj_carman) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE DOES NOT START ON WinXP Pro Initial Comment: Installed Python 2.3.4 on WinXP Pro on Dell Inspiron. Command line interpreter works fine, but the IDLE GUI will not start. Only occurs on Dell Inspiron; cannot reproduce this on other machines. McAffee firewall software is disabled. Any ideas? ---------------------------------------------------------------------- >Comment By: Snake (gj_carman) Date: 2004-09-01 12:09 Message: Logged In: YES user_id=1112369 When clicking the shortcut via the Start menu, the hourglass briefly appears but IDLE does not start. The WinXP personal firewall is not enabled. There is McAfee security software running, but the same behavior occurs when the software is disabled. When running Idle from the commandline, get the following output: C:\Python23\Lib\idlelib>idle.py Traceback (most recent call last): File "C:\Python23\Lib\idlelib\idle.py", line 23, in ? idlelib.PyShell.main() File "C:\Python23\lib\idlelib\PyShell.py", line 1287, in main flist.pyshell = PyShell(flist) File "C:\Python23\lib\idlelib\PyShell.py", line 769, in __init__ self.interp.start_subprocess() File "C:\Python23\lib\idlelib\PyShell.py", line 369, in start_subprocess self.transfer_path() File "C:\Python23\lib\idlelib\PyShell.py", line 438, in transfer_path self.runcommand("""if 1: File "C:\Python23\lib\idlelib\PyShell.py", line 655, in runcommand self.rpcclt.remotequeue("exec", "runcode", (code,), {}) File "C:\Python23\lib\idlelib\rpc.py", line 214, in remotequeue return self.asyncreturn(seq) File "C:\Python23\lib\idlelib\rpc.py", line 238, in asyncreturn response = self.getresponse(seq, wait=0.05) File "C:\Python23\lib\idlelib\rpc.py", line 278, in getresponse response = self._getresponse(myseq, wait) File "C:\Python23\lib\idlelib\rpc.py", line 298, in _getresponse response = self.pollresponse(myseq, wait) File "C:\Python23\lib\idlelib\rpc.py", line 423, in pollresponse message = self.pollmessage(wait) File "C:\Python23\lib\idlelib\rpc.py", line 375, in pollmessage packet = self.pollpacket(wait) File "C:\Python23\lib\idlelib\rpc.py", line 347, in pollpacket if not self.ioready(wait): File "C:\Python23\lib\idlelib\rpc.py", line 337, in ioready r, w, x = select.select([self.sock.fileno()], [], [], wait) select.error: (10022, 'An invalid argument was supplied') ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-29 15:18 Message: Logged In: YES user_id=149084 More information is needed, what does "will not start" mean? Open a command window, cd to \python23\Lib\idlelib and run ..\..\python .\PyShell.py Post all error message in command window or in the IDLE GUI here. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 From noreply at sourceforge.net Thu Sep 2 08:20:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 08:21:04 2004 Subject: [ python-Bugs-1007249 ] SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Message-ID: Bugs item #1007249, was opened at 2004-08-11 15:11 Message generated for change (Comment added) made by mhertha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 Category: Build Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Hye-Shik Chang (perky) Summary: SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Initial Comment: This bug report is similar to #1005737 only a different platform. MIPSpro Compilers: Version 7.3.1.3m Error message: --- start cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1053 There are too many initializers for a declared aggregate. { REGISTRY_KSX1001, REGISTRY_SENTINEL }, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1058 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0201_R, REGISTRY_JISX0208_O, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1064 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1070 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_KSX1001, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1077 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2004_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1084 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2000_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1091 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ --- end The manpage for cc describes the differences between gcc and mipspro: .... * The gcc compiler is more lax about accepting non-static initializers, extra parentheses, and the use of non-compile-time constants. The MIPSpro compilers adhere more closely to the ANSI standard. .... I found no compiler-option to solve this for the MipsPro compiler. Seems to be a hard work to solve this :-(. ---------------------------------------------------------------------- >Comment By: Maik Hertha (mhertha) Date: 2004-09-02 08:20 Message: Logged In: YES user_id=768223 The Patch doen't work complete. As the problem was easier :-) I could solve it. Enclosed the patch for SGI MipsPro compilers. It is diff'ed against the patched Modules/cjkcodecs/_codecs_iso2022.c. Sorry for the delayed response. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-19 19:58 Message: Logged In: YES user_id=55188 I think the error should be fixed in CVS now. If you still have a problem to compile it, please give me another comment. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 15:05 Message: Logged In: YES user_id=55188 Would you test a patch attached in Bug #1005737? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 From noreply at sourceforge.net Thu Sep 2 14:26:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 14:26:26 2004 Subject: [ python-Bugs-1015249 ] cgi.FieldStorage.__len__ eventually throws TypeError Message-ID: Bugs item #1015249, was opened at 2004-08-24 15:32 Message generated for change (Comment added) made by yxcv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015249&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage.__len__ eventually throws TypeError Initial Comment: This makes it hazardous to do the following: fs = cgi.FieldStorage(...) if fs: ... Suggestions: 1) Fix __len__; sorry, but I don't know how. 2) Create FieldStorage.__nonzero__; a hack. 3) ? ---------------------------------------------------------------------- >Comment By: Andreas Ames (yxcv) Date: 2004-09-02 14:26 Message: Logged In: YES user_id=898176 For a code snippet please look at: http://mail.python.org/pipermail/python-list/2004-August/235988.html AFAIK, cgi.FieldStorage is meant to either (sort of) 'be' a list or a file after having parsed the request. So one could possibly take the builtin file object as kind of evidence: >>> f = file('/etc/passwd') >>> len(f) Traceback (most recent call last): File "", line 1, in ? TypeError: len() of unsized object >>> if f: ... print 'yes' ... else: ... print 'no' ... yes >>> ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 16:47 Message: Logged In: YES user_id=469548 As far as I can tell, cgi.FieldStorage.__len__ only raises a TypeError if the FieldStorage is not indexable. It's reasonable not to support len() on an unindexable FieldStorage. I'm just wondering why you would want to do: fs = cgi.FieldStorage(...) if fs: ... Defining __nonzero__ seems reasonable if there's a reason for testing a FieldStorage for truth value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015249&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:39:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:39:46 2004 Subject: [ python-Bugs-1020605 ] senddigest error Message-ID: Bugs item #1020605, was opened at 2004-09-01 18:10 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020605&group_id=5470 Category: None Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: James O'Kane (jo2y) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: senddigest error Initial Comment: I am having the same error as mentioned in this post: http://mail.python.org/pipermail/mailman-developers/2004-June/016931.html My traceback: Aug 30 16:52:38 2004 (14988) Traceback (most recent call last): File "/usr/opt/mailman//Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/opt/mailman//Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/opt/mailman//Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/opt/mailman//Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 82, in process send_digests(mlist, mboxfp) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/opt/mailman//Mailman/Handlers/Scrubber.py", line 257, in process url = save_attachment(mlist, part, dir) File "/usr/opt/mailman//Mailman/Handlers/Scrubber.py", line 348, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/opt/mailman//pythonlib/email/Message.py", line 683, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/opt/mailman//pythonlib/email/Message.py", line 566, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/opt/mailman//pythonlib/email/Message.py", line 516, in _get_params_preserve params = Utils.decode_params(params) File "/usr/opt/mailman//pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/opt/mailman//pythonlib/email/Utils.py", line 283, in decode_rfc2231 charset, language, s = s.split("'", 2) ValueError: unpack list of wrong size s at this point has the value: NET News.com.pdf What I think are the relavent headers: X-Mailer: Apple Mail (2.619) --Apple-Mail-7--372163126 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644;CNET News.com.pdf" Content-Disposition: inline;silicon | C"; filename*1="NET News.com.pdf" If you need more information than this, I'll need to run it past the sender of the message, first. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-09-02 13:39 Message: Logged In: YES user_id=31392 Is this a Python bug? It looks like a Mailman problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020605&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:40:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:40:05 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 20:00 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antonio Rodriguez (antrod) >Assigned to: Jeremy Hylton (jhylton) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:40:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:40:50 2004 Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth Message-ID: Bugs item #1016563, was opened at 2004-08-26 07:14 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Mussenbrock (mussenbrock) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 bug in proxy auth Initial Comment: in urllib2.py: line 502 should be: ... user_pass = base64.encodestring('%s:%s' % (unquote (user), unquote(password))).strip() the '.strip()' is missing in the current version ("2.1"). this makes an additonal '\n' at the end of user_pass. So there will be an empty line in the http header, which is buggy. (see also line 645, where the .strip() is right in place!). Best regards, Christoph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 From noreply at sourceforge.net Thu Sep 2 17:51:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 17:51:26 2004 Subject: [ python-Bugs-1020605 ] senddigest error Message-ID: Bugs item #1020605, was opened at 2004-09-01 14:10 Message generated for change (Comment added) made by jo2y You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020605&group_id=5470 Category: None Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: James O'Kane (jo2y) Assigned to: Barry A. Warsaw (bwarsaw) Summary: senddigest error Initial Comment: I am having the same error as mentioned in this post: http://mail.python.org/pipermail/mailman-developers/2004-June/016931.html My traceback: Aug 30 16:52:38 2004 (14988) Traceback (most recent call last): File "/usr/opt/mailman//Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/opt/mailman//Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/opt/mailman//Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/opt/mailman//Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 82, in process send_digests(mlist, mboxfp) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/opt/mailman//Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/opt/mailman//Mailman/Handlers/Scrubber.py", line 257, in process url = save_attachment(mlist, part, dir) File "/usr/opt/mailman//Mailman/Handlers/Scrubber.py", line 348, in save_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/opt/mailman//pythonlib/email/Message.py", line 683, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/opt/mailman//pythonlib/email/Message.py", line 566, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/opt/mailman//pythonlib/email/Message.py", line 516, in _get_params_preserve params = Utils.decode_params(params) File "/usr/opt/mailman//pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/opt/mailman//pythonlib/email/Utils.py", line 283, in decode_rfc2231 charset, language, s = s.split("'", 2) ValueError: unpack list of wrong size s at this point has the value: NET News.com.pdf What I think are the relavent headers: X-Mailer: Apple Mail (2.619) --Apple-Mail-7--372163126 Content-Transfer-Encoding: base64 Content-Type: application/pdf; x-unix-mode=0644;CNET News.com.pdf" Content-Disposition: inline;silicon | C"; filename*1="NET News.com.pdf" If you need more information than this, I'll need to run it past the sender of the message, first. ---------------------------------------------------------------------- >Comment By: James O'Kane (jo2y) Date: 2004-09-02 11:51 Message: Logged In: YES user_id=7767 Oh. Yes, you're probably right. I saw someone on the mailman mailing list with the same problem and a response from Barry Warsaw asking for a ticket to be created, and a link. I didn't look close to see which project I was leaving a ticket. I assumed it was a Mailman queue. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-09-02 09:39 Message: Logged In: YES user_id=31392 Is this a Python bug? It looks like a Mailman problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020605&group_id=5470 From noreply at sourceforge.net Thu Sep 2 18:56:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 18:56:51 2004 Subject: [ python-Bugs-1021318 ] PyThreadState_Next not thread safe? Message-ID: Bugs item #1021318, was opened at 2004-09-02 16:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021318&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_Next not thread safe? Initial Comment: I can't convince myself that PyThreadState_Next is thread safe even if the GIL is held because PyGILState_Release can delete a thread state after releasing the GIL if the gilstate_counter reaches 0. So another thread could be deleting a thread state my thread is referencing. If the GIL was held when the thread state was deleted, the I think the next function would be thread safe because new thread states are always added to the front of the list. If these functions should work when the GIL is not held, the head_mutex in pystate.c probably needs to be exposed in some manner so code can lock it, iterate through the threads, and then unlock it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021318&group_id=5470 From noreply at sourceforge.net Thu Sep 2 22:48:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 22:48:21 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 22:00 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antonio Rodriguez (antrod) Assigned to: Jeremy Hylton (jhylton) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 22:48 Message: Logged In: YES user_id=9205 The \r\n (CRLF) line is required by RFC 2616 section 5: a CRLF ends the headers. The line must not be treated as part of the payload, the message-body begins after the newline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Thu Sep 2 23:09:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 23:09:35 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 15:00 Message generated for change (Comment added) made by antrod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antonio Rodriguez (antrod) Assigned to: Jeremy Hylton (jhylton) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- >Comment By: Antonio Rodriguez (antrod) Date: 2004-09-02 16:09 Message: Logged In: YES user_id=714839 Calvin, Sorry, I should have been more clear in my original post. My *skim* of the RFC is that one blank line is required (so \r\n at the end of the last header and then another \r\n). What I think this is doing is inserting two blank lines (so 3 total \r\n) which is not (as far as I can see in the RFC). Should I append some test code to make it clearer? Antonio ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 15:48 Message: Logged In: YES user_id=9205 The \r\n (CRLF) line is required by RFC 2616 section 5: a CRLF ends the headers. The line must not be treated as part of the payload, the message-body begins after the newline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Thu Sep 2 23:26:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 23:26:39 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 22:00 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antonio Rodriguez (antrod) Assigned to: Jeremy Hylton (jhylton) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 23:26 Message: Logged In: YES user_id=9205 Hm, the code adds just two CRLFs: >>> h = ["Header: value"] >>> h.extend(("", "")) >>> "\r\n".join(h) 'Header: value\r\n\r\n' If you see 3 \r\n in your application it must be something else, perhaps the header value had an additional line ending in it. ---------------------------------------------------------------------- Comment By: Antonio Rodriguez (antrod) Date: 2004-09-02 23:09 Message: Logged In: YES user_id=714839 Calvin, Sorry, I should have been more clear in my original post. My *skim* of the RFC is that one blank line is required (so \r\n at the end of the last header and then another \r\n). What I think this is doing is inserting two blank lines (so 3 total \r\n) which is not (as far as I can see in the RFC). Should I append some test code to make it clearer? Antonio ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 22:48 Message: Logged In: YES user_id=9205 The \r\n (CRLF) line is required by RFC 2616 section 5: a CRLF ends the headers. The line must not be treated as part of the payload, the message-body begins after the newline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Thu Sep 2 23:37:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 23:37:07 2004 Subject: [ python-Bugs-1017978 ] IDLE DOES NOT START ON WinXP Pro Message-ID: Bugs item #1017978, was opened at 2004-08-27 19:23 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Snake (gj_carman) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE DOES NOT START ON WinXP Pro Initial Comment: Installed Python 2.3.4 on WinXP Pro on Dell Inspiron. Command line interpreter works fine, but the IDLE GUI will not start. Only occurs on Dell Inspiron; cannot reproduce this on other machines. McAffee firewall software is disabled. Any ideas? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-09-02 16:37 Message: Logged In: YES user_id=149084 Strange. Although IDLE has been communicating with its subprocess while registering methods, either the socket has gone away or it doesn't have a fileno() method. It always fails at this point? Try adding the following debug code just before line 337 in rpc.py: print>>sys.__stderr__, "*** self.sock: ", self.sock print>>sys.__stderr__, "*** self.sock.fileno(): ", self.sock.fileno() and post the results here. Thanks. ---------------------------------------------------------------------- Comment By: Snake (gj_carman) Date: 2004-09-01 14:09 Message: Logged In: YES user_id=1112369 When clicking the shortcut via the Start menu, the hourglass briefly appears but IDLE does not start. The WinXP personal firewall is not enabled. There is McAfee security software running, but the same behavior occurs when the software is disabled. When running Idle from the commandline, get the following output: C:\Python23\Lib\idlelib>idle.py Traceback (most recent call last): File "C:\Python23\Lib\idlelib\idle.py", line 23, in ? idlelib.PyShell.main() File "C:\Python23\lib\idlelib\PyShell.py", line 1287, in main flist.pyshell = PyShell(flist) File "C:\Python23\lib\idlelib\PyShell.py", line 769, in __init__ self.interp.start_subprocess() File "C:\Python23\lib\idlelib\PyShell.py", line 369, in start_subprocess self.transfer_path() File "C:\Python23\lib\idlelib\PyShell.py", line 438, in transfer_path self.runcommand("""if 1: File "C:\Python23\lib\idlelib\PyShell.py", line 655, in runcommand self.rpcclt.remotequeue("exec", "runcode", (code,), {}) File "C:\Python23\lib\idlelib\rpc.py", line 214, in remotequeue return self.asyncreturn(seq) File "C:\Python23\lib\idlelib\rpc.py", line 238, in asyncreturn response = self.getresponse(seq, wait=0.05) File "C:\Python23\lib\idlelib\rpc.py", line 278, in getresponse response = self._getresponse(myseq, wait) File "C:\Python23\lib\idlelib\rpc.py", line 298, in _getresponse response = self.pollresponse(myseq, wait) File "C:\Python23\lib\idlelib\rpc.py", line 423, in pollresponse message = self.pollmessage(wait) File "C:\Python23\lib\idlelib\rpc.py", line 375, in pollmessage packet = self.pollpacket(wait) File "C:\Python23\lib\idlelib\rpc.py", line 347, in pollpacket if not self.ioready(wait): File "C:\Python23\lib\idlelib\rpc.py", line 337, in ioready r, w, x = select.select([self.sock.fileno()], [], [], wait) select.error: (10022, 'An invalid argument was supplied') ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-29 17:18 Message: Logged In: YES user_id=149084 More information is needed, what does "will not start" mean? Open a command window, cd to \python23\Lib\idlelib and run ..\..\python .\PyShell.py Post all error message in command window or in the IDLE GUI here. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 From noreply at sourceforge.net Fri Sep 3 06:00:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 06:00:19 2004 Subject: [ python-Bugs-1021596 ] Trivial fix for obscure bug in os.urandom() Message-ID: Bugs item #1021596, was opened at 2004-09-03 00:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021596&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Mathewson (nickm) Assigned to: Nobody/Anonymous (nobody) Summary: Trivial fix for obscure bug in os.urandom() Initial Comment: The new os.urandom function checks for whether it has set _urandomfd with "if not _urandomfd:" . But this is incorrect; on some systems, if fd 0 has been closed, it is possible for _urandomfd to be 0. Instead, the check should be "if _urandomfd is None". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021596&group_id=5470 From noreply at sourceforge.net Fri Sep 3 07:27:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 07:27:33 2004 Subject: [ python-Bugs-1021621 ] use first_name, not first, in code samples Message-ID: Bugs item #1021621, was opened at 2004-09-02 22:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Steve R. Hastings (steveha) Assigned to: Nobody/Anonymous (nobody) Summary: use first_name, not first, in code samples Initial Comment: Low priority documentation request. I'm studying the documentation on how to write a C module. http://docs.python.org/ext/node22.html Please update the sample code in the documentation to use "first_name" rather than "first" and "last_name" rather than "last". When I first studied the code and saw "first" and "last" members in a structure, I thought those were for a linked list of some sort. Much later in the code I realized that the object was supposed to have a first name and a last name, and there was no linked list at all. "first_name" would be much more self-documenting than "first". An acceptable alternative would be a comment after the "first" declaration, saying: /* first name */ This is a small point, but I think it would be an improvement to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 From noreply at sourceforge.net Fri Sep 3 07:28:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 07:28:15 2004 Subject: [ python-Bugs-1021621 ] use first_name, not first, in code samples Message-ID: Bugs item #1021621, was opened at 2004-09-02 22:27 Message generated for change (Settings changed) made by steveha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None >Priority: 1 Submitted By: Steve R. Hastings (steveha) Assigned to: Nobody/Anonymous (nobody) Summary: use first_name, not first, in code samples Initial Comment: Low priority documentation request. I'm studying the documentation on how to write a C module. http://docs.python.org/ext/node22.html Please update the sample code in the documentation to use "first_name" rather than "first" and "last_name" rather than "last". When I first studied the code and saw "first" and "last" members in a structure, I thought those were for a linked list of some sort. Much later in the code I realized that the object was supposed to have a first name and a last name, and there was no linked list at all. "first_name" would be much more self-documenting than "first". An acceptable alternative would be a comment after the "first" declaration, saying: /* first name */ This is a small point, but I think it would be an improvement to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 From noreply at sourceforge.net Fri Sep 3 12:59:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 12:59:26 2004 Subject: [ python-Bugs-1021621 ] use first_name, not first, in code samples Message-ID: Bugs item #1021621, was opened at 2004-09-03 06:27 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 1 Submitted By: Steve R. Hastings (steveha) Assigned to: Nobody/Anonymous (nobody) Summary: use first_name, not first, in code samples Initial Comment: Low priority documentation request. I'm studying the documentation on how to write a C module. http://docs.python.org/ext/node22.html Please update the sample code in the documentation to use "first_name" rather than "first" and "last_name" rather than "last". When I first studied the code and saw "first" and "last" members in a structure, I thought those were for a linked list of some sort. Much later in the code I realized that the object was supposed to have a first name and a last name, and there was no linked list at all. "first_name" would be much more self-documenting than "first". An acceptable alternative would be a comment after the "first" declaration, saying: /* first name */ This is a small point, but I think it would be an improvement to the documentation. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-03 11:59 Message: Logged In: YES user_id=6656 FWIW, I agree. I'm attempting to rewrite the extending and embedding manual, and yes, this is one of the things I've changed. I've just uploaded my latest draft to http://starship.python.net/crew/mwh/toext/ which gets a little way into the area of defining new types. I'd really appreciate your comments! (to mwh@python.net, please). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&group_id=5470 From noreply at sourceforge.net Fri Sep 3 13:34:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 13:34:52 2004 Subject: [ python-Bugs-1021756 ] 2.4a3: unhelpful error message from distutils Message-ID: Bugs item #1021756, was opened at 2004-09-03 13:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021756&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4a3: unhelpful error message from distutils Initial Comment: C:\somewhere> python Python 2.4a3 (#56, Sep 2 2004, 20:50:21) ... C:\somewhere> python setup.py build running build_ext Traceback (most recent call last): File "setup.py", line 19, in ? ext_modules = [ File "C:\python24\lib\distutils\core.py", line 150, in setup dist.run_commands() File "C:\python24\lib\distutils\dist.py", line 991, in run_commands self.run_command(cmd) File "C:\python24\lib\distutils\dist.py", line 1011, in run_command cmd_obj.run() File "C:\python24\lib\distutils\command\build_ext.py", line 243, in run force=self.force) File "C:\python24\lib\distutils\ccompiler.py", line 1177, in new_compiler return klass (None, dry_run, force) File "C:\python24\lib\distutils\msvccompiler.py", line 206, in __init__ self.__macros = MacroExpander(self.__version) File "C:\python24\lib\distutils\msvccompiler.py", line 112, in __init__ self.load_macros(version) File "C:\python24\lib\distutils\msvccompiler.py", line 128, in load_macros self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1") File "C:\python24\lib\distutils\msvccompiler.py", line 118, in set_macro self.macros["$(%s)" % macro] = d[key] KeyError: 'sdkinstallrootv1.1' I suppose it's trying to tell me something, but I'm not sure what. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021756&group_id=5470 From noreply at sourceforge.net Fri Sep 3 13:38:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 13:38:19 2004 Subject: [ python-Bugs-1018815 ] re.sub: two-digit group-reference hangs Message-ID: Bugs item #1018815, was opened at 2004-08-30 03:36 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dyck (jmdyck) Assigned to: Fredrik Lundh (effbot) Summary: re.sub: two-digit group-reference hangs Initial Comment: Python 2.3.3 (#2, Feb 17 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 I think this affects 2.4 as well. If you invoke re.sub(), and the replacement contains a two-digit group-reference, it hangs. E.g. try print re.sub( r'(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)', r'\10', 'abcdefghijklm' ) Problem is infinite loop in sre_parse.py. I've attached a change that I think fixes it. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 13:38 Message: Logged In: YES user_id=38376 Still there in 2.4a3, it seems. ---------------------------------------------------------------------- Comment By: Michael Dyck (jmdyck) Date: 2004-08-30 03:45 Message: Logged In: YES user_id=663727 It sounds like this bug was fixed by patch 1018386 just yesterday! (Please check.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 From noreply at sourceforge.net Fri Sep 3 13:44:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 13:44:55 2004 Subject: [ python-Bugs-1018815 ] re.sub: two-digit group-reference hangs Message-ID: Bugs item #1018815, was opened at 2004-08-30 03:36 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dyck (jmdyck) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.sub: two-digit group-reference hangs Initial Comment: Python 2.3.3 (#2, Feb 17 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 I think this affects 2.4 as well. If you invoke re.sub(), and the replacement contains a two-digit group-reference, it hangs. E.g. try print re.sub( r'(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)', r'\10', 'abcdefghijklm' ) Problem is infinite loop in sre_parse.py. I've attached a change that I think fixes it. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 13:44 Message: Logged In: YES user_id=38376 Assigning to Gustavo, who's reviewing #1018386 at the moment. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 13:38 Message: Logged In: YES user_id=38376 Still there in 2.4a3, it seems. ---------------------------------------------------------------------- Comment By: Michael Dyck (jmdyck) Date: 2004-08-30 03:45 Message: Logged In: YES user_id=663727 It sounds like this bug was fixed by patch 1018386 just yesterday! (Please check.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 From noreply at sourceforge.net Fri Sep 3 14:04:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 14:04:14 2004 Subject: [ python-Bugs-817234 ] re.finditer hangs on final empty match Message-ID: Bugs item #817234, was opened at 2003-10-03 17:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.finditer hangs on final empty match Initial Comment: The iterator returned by re.finditer appears to not terminate if the final match is empty, but rather keeps returning the final (empty) match. Is this a bug in _sre? If so, I'll be happy to file it, though fixing it is a bit beyond my _sre experience level at this point. The solution would appear to be to either a check for duplicate match in iterator.next(), or to increment position by one after returning an empty match (which should be OK, because if a non-empty match started at that location, we would have returned it instead of the empty match). Code to illustrate the failure: from re import finditer last = None for m in finditer( ".*", "asdf" ): if last == m.span(): print "duplicate match:", last break print m.group(), m.span() last = m.span() --- asdf (0, 4) (4, 4) duplicate match: (4, 4) --- findall works: print re.findall( ".*", "asdf" ) ['asdf', ''] Workaround is to explicitly check for a duplicate span, as I did above, or to check for a duplicate end(), which avoids the final empty match Seo Sanghyeon sent the following fix to python-dev list: Attached one line patch fixes re.finditer bug reported by Kevin J. Butler. I read cvs log to find out why this code is introduced, and it seems to be related to SF bug #581080. But that bug didn't appear after my patch, so I wonder why it was introduced in the first place. It seems beyond my understanding. Please enlighten me. To test: #581080 import re list(re.finditer('\s', 'a b')) # expected: one item list # bug: hang #Kevin J. Butler import re list(re.finditer('.*', 'asdf')) # expected: two item list (?) # bug: hang Seo Sanghyeon -------------- next part -------------- ? patch Index: Modules/_sre.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v retrieving revision 2.99 diff -c -r2.99 _sre.c *** Modules/_sre.c 26 Jun 2003 14:41:08 -0000 2.99 --- Modules/_sre.c 2 Oct 2003 03:48:55 -0000 *************** *** 3062,3069 **** match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if ((status == 0 || state->ptr == state->start) && ! state->ptr < state->end) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; --- 3062,3068 ---- match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if (status == 0 || state->ptr == state->start) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 14:04 Message: Logged In: YES user_id=38376 Still there in 2.4a3, as the following revised example shows: import re m = re.finditer(".*", "asdf") print m.next().span() print m.next().span() print m.next().span() # this should raise an exception Gustavo, can you look at this patch too? ---------------------------------------------------------------------- Comment By: Kevin J. Butler (kevinbutler) Date: 2003-10-03 20:16 Message: Logged In: YES user_id=117665 The above patch does resolve the problem. The code was introduced in rev 2.85 http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_sre.c to resolve bug 581080 http://sourceforge.net/tracker/index.php?func=detail&aid=581080&group_id=5470&atid=105470 but removing this line does not re-introduce that bug. Thanks, and kudos to Seo... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 From noreply at sourceforge.net Fri Sep 3 15:59:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 15:59:32 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 15:49 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Paul D. Lusk (plusk) Date: 2004-09-03 09:59 Message: Logged In: YES user_id=1083789 Fixed in 2.4a3 ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 10:55 Message: Logged In: YES user_id=1083789 It is the final inet4 test failing. inet4 is 1. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 10:14 Message: Logged In: YES user_id=43607 Putting #include "addrinfo.h" outside the #if 0/#endif in getaddrinfo.c. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 09:13 Message: Logged In: YES user_id=21627 plusk, can you find out which of the "goto bad" statements was taken, by running the program separately, and adding printf calls? Historically, Python had to make these tests, because many platforms indeed *have* a broken getaddrinfo. sjoerd, in what way does exactly what fix the compilation problem on Cygwin? ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 08:59 Message: Logged In: YES user_id=43607 This also fixes the compilation problem on Cygwin. See bug 1001857. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:25 Message: Logged In: YES user_id=1083789 But configure thinks it's buggy: configure:14229: checking getaddrinfo bug configure:14332: gcc -o conftest -g -O2 conftest.c -lcl - lnsl -lrt -ldld -lpthread >&5 configure:14335: $? = 0 configure:14337: ./conftest configure:14340: $? = 1 configure: program exited with status 1 configure: failed program was: | #line 14236 "configure" | /* confdefs.h. */ | | #define _GNU_SOURCE 1 | #define _NETBSD_SOURCE 1 | #define __BSD_VISIBLE 1 | #define _XOPEN_SOURCE 600 | #define _XOPEN_SOURCE_EXTENDED 1 | #define _POSIX_C_SOURCE 200112L | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_BSDTTY_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_LOCK_H 1 | #define HAVE_SYS_MODEM_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TIMES_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_TERM_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYSEXITS_H 1 | #define HAVE_DIRENT_H 1 | #define MAJOR_IN_SYSMACROS 1 | #define _LARGEFILE_SOURCE 1 | #define _FILE_OFFSET_BITS 64 | #if defined(SCO_DS) | #undef _OFF_T | #endif | #define RETSIGTYPE void | #define SIZEOF_INT 4 | #define SIZEOF_LONG 4 | #define SIZEOF_VOID_P 4 | #define SIZEOF_SHORT 2 | #define SIZEOF_FLOAT 4 | #define SIZEOF_DOUBLE 8 | #define SIZEOF_FPOS_T 8 | #define HAVE_LONG_LONG 1 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_OFF_T 8 | #define HAVE_LARGEFILE_SUPPORT 1 | #define SIZEOF_TIME_T 4 | #define SIZEOF_PTHREAD_T 4 | #define HAVE_LIBDLD 1 | #define _REENTRANT 1 | #define WITH_THREAD 1 | #define _POSIX_THREADS 1 | #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 | #define HAVE_PTHREAD_SIGMASK 1 | #define WITH_DOC_STRINGS 1 | #define WITH_PYMALLOC 1 | #define HAVE_DLOPEN 1 | #define HAVE_DYNAMIC_LOADING 1 | #define HAVE_ALARM 1 | #define HAVE_CHOWN 1 | #define HAVE_CLOCK 1 | #define HAVE_CONFSTR 1 | #define HAVE_CTERMID 1 | #define HAVE_EXECV 1 | #define HAVE_FORK 1 | #define HAVE_FPATHCONF 1 | #define HAVE_FTIME 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_GAI_STRERROR 1 | #define HAVE_GETGROUPS 1 | #define HAVE_GETLOGIN 1 | #define HAVE_GETPEERNAME 1 | #define HAVE_GETPGID 1 | #define HAVE_GETPID 1 | #define HAVE_GETPRIORITY 1 | #define HAVE_GETPWENT 1 | #define HAVE_GETSID 1 | #define HAVE_GETWD 1 | #define HAVE_KILL 1 | #define HAVE_KILLPG 1 | #define HAVE_LCHOWN 1 | #define HAVE_LSTAT 1 | #define HAVE_MKFIFO 1 | #define HAVE_MKNOD 1 | #define HAVE_MKTIME 1 | #define HAVE_NICE 1 | #define HAVE_PATHCONF 1 | #define HAVE_PAUSE 1 | #define HAVE_PLOCK 1 | #define HAVE_POLL 1 | #define HAVE_PUTENV 1 | #define HAVE_READLINK 1 | #define HAVE_REALPATH 1 | #define HAVE_SELECT 1 | #define HAVE_SETGID 1 | #define HAVE_SETLOCALE 1 | #define HAVE_SETREGID 1 | #define HAVE_SETREUID 1 | #define HAVE_SETSID 1 | #define HAVE_SETPGID 1 | #define HAVE_SETPGRP 1 | #define HAVE_SETUID 1 | #define HAVE_SETVBUF 1 | #define HAVE_SNPRINTF 1 | #define HAVE_SIGACTION 1 | #define HAVE_SIGINTERRUPT 1 | #define HAVE_SIGRELSE 1 | #define HAVE_STRFTIME 1 | #define HAVE_SYSCONF 1 | #define HAVE_TCGETPGRP 1 | #define HAVE_TCSETPGRP 1 | #define HAVE_TEMPNAM 1 | #define HAVE_TIMES 1 | #define HAVE_TMPFILE 1 | #define HAVE_TMPNAM 1 | #define HAVE_TRUNCATE 1 | #define HAVE_UNAME 1 | #define HAVE_UTIMES 1 | #define HAVE_WAITPID 1 | #define HAVE_WCSCOLL 1 | #define HAVE_CHROOT 1 | #define HAVE_LINK 1 | #define HAVE_SYMLINK 1 | #define HAVE_FCHDIR 1 | #define HAVE_FSYNC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_GETPAGESIZE 1 | #define HAVE_INET_ATON 1 | #define HAVE_INET_PTON 1 | #define HAVE_SETGROUPS 1 | #define HAVE_FSEEKO 1 | #define HAVE_FSTATVFS 1 | #define HAVE_FTELLO 1 | #define HAVE_STATVFS 1 | #define HAVE_DUP2 1 | #define HAVE_GETCWD 1 | #define HAVE_STRDUP 1 | #define HAVE_STRERROR 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPGRP 1 | #define HAVE_SETPGRP 1 | #define HAVE_GETTIMEOFDAY 1 | /* end confdefs.h. */ | | #include | #include | #include | #include | #include | | main() | { | int passive, gaierr, inet4 = 0, inet6 = 0; | struct addrinfo hints, *ai, *aitop; | char straddr[INET6_ADDRSTRLEN], strport[16]; | | for (passive = 0; passive <= 1; passive++) { | memset(&hints, 0, sizeof(hints)); | hints.ai_family = AF_UNSPEC; | hints.ai_flags = passive ? AI_PASSIVE : 0; | hints.ai_socktype = SOCK_STREAM; | hints.ai_protocol = IPPROTO_TCP; | if ((gaierr = getaddrinfo(NULL, "54321", &hints, &aitop)) ! = 0) { | (void)gai_strerror(gaierr); | goto bad; | } | for (ai = aitop; ai; ai = ai->ai_next) { | if (ai->ai_addr == NULL || | ai->ai_addrlen == 0 || | getnameinfo(ai->ai_addr, ai->ai_addrlen, | straddr, sizeof(straddr), strport, sizeof (strport), | NI_NUMERICHOST|NI_NUMERICSERV) != 0) { | goto bad; | } | switch (ai->ai_family) { | case AF_INET: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "0.0.0.0") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "127.0.0.1") != 0) { | goto bad; | } | } | inet4++; | break; | case AF_INET6: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "::") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "::1") != 0) { | goto bad; | } | } | inet6++; | break; | case AF_UNSPEC: | goto bad; | break; | default: | /* another family support? */ | break; | } | } | } | | if (!(inet4 == 0 || inet4 == 2)) | goto bad; | if (!(inet6 == 0 || inet6 == 2)) | goto bad; | | if (aitop) | freeaddrinfo(aitop); | exit(0); | | bad: | if (aitop) | freeaddrinfo(aitop); | exit(1); | } | configure:14351: result: buggy ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 13:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Fri Sep 3 16:10:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 16:10:32 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 15:00 Message generated for change (Comment added) made by antrod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antonio Rodriguez (antrod) Assigned to: Jeremy Hylton (jhylton) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- >Comment By: Antonio Rodriguez (antrod) Date: 2004-09-03 09:10 Message: Logged In: YES user_id=714839 Calvin, After much checking, I've discovered you are indeed correct. A million apologies for raising a false alarm. I was confused by the line: h.extend(("", "")) In that it would seem to add two blank lines when it really just adds two \r\n s. Anyhow, I guess this officially closes this. Again, thanks for the prompt response. AR ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 16:26 Message: Logged In: YES user_id=9205 Hm, the code adds just two CRLFs: >>> h = ["Header: value"] >>> h.extend(("", "")) >>> "\r\n".join(h) 'Header: value\r\n\r\n' If you see 3 \r\n in your application it must be something else, perhaps the header value had an additional line ending in it. ---------------------------------------------------------------------- Comment By: Antonio Rodriguez (antrod) Date: 2004-09-02 16:09 Message: Logged In: YES user_id=714839 Calvin, Sorry, I should have been more clear in my original post. My *skim* of the RFC is that one blank line is required (so \r\n at the end of the last header and then another \r\n). What I think this is doing is inserting two blank lines (so 3 total \r\n) which is not (as far as I can see in the RFC). Should I append some test code to make it clearer? Antonio ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 15:48 Message: Logged In: YES user_id=9205 The \r\n (CRLF) line is required by RFC 2616 section 5: a CRLF ends the headers. The line must not be treated as part of the payload, the message-body begins after the newline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Fri Sep 3 17:04:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 17:04:30 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 20:00 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Antonio Rodriguez (antrod) Assigned to: Jeremy Hylton (jhylton) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- Comment By: Antonio Rodriguez (antrod) Date: 2004-09-03 14:10 Message: Logged In: YES user_id=714839 Calvin, After much checking, I've discovered you are indeed correct. A million apologies for raising a false alarm. I was confused by the line: h.extend(("", "")) In that it would seem to add two blank lines when it really just adds two \r\n s. Anyhow, I guess this officially closes this. Again, thanks for the prompt response. AR ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 21:26 Message: Logged In: YES user_id=9205 Hm, the code adds just two CRLFs: >>> h = ["Header: value"] >>> h.extend(("", "")) >>> "\r\n".join(h) 'Header: value\r\n\r\n' If you see 3 \r\n in your application it must be something else, perhaps the header value had an additional line ending in it. ---------------------------------------------------------------------- Comment By: Antonio Rodriguez (antrod) Date: 2004-09-02 21:09 Message: Logged In: YES user_id=714839 Calvin, Sorry, I should have been more clear in my original post. My *skim* of the RFC is that one blank line is required (so \r\n at the end of the last header and then another \r\n). What I think this is doing is inserting two blank lines (so 3 total \r\n) which is not (as far as I can see in the RFC). Should I append some test code to make it clearer? Antonio ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-02 20:48 Message: Logged In: YES user_id=9205 The \r\n (CRLF) line is required by RFC 2616 section 5: a CRLF ends the headers. The line must not be treated as part of the payload, the message-body begins after the newline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Fri Sep 3 17:31:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 17:31:59 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Fri Sep 3 19:23:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 19:23:19 2004 Subject: [ python-Bugs-776311 ] Regular expression failure of the sre engine Message-ID: Bugs item #776311, was opened at 2003-07-23 15:15 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776311&group_id=5470 Category: Regular Expressions Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wolfgang Grafen (grafen) Assigned to: Fredrik Lundh (effbot) Summary: Regular expression failure of the sre engine Initial Comment: Don't depreciate pre as we all will loose a useful verification tool for sre! >From time to time I have situations where I wonder why re(sre) doesn't match its input. Then I change to pre (import pre as re) and several times it happened that pre worked fine while sre did not. Sorry that I didn't track down the error but if you are interested in the testcase I attached the test case for you. (This failure is in a regular expression which maches a complete pattern of a VHDL Architecture to apply a patch on it so it was quick hack but a large regex. The other failures I cannot remember what it was, sorry) Regards Wolfgang Grafen --------------------------------------- I will be absent until 5 September 2003 --------------------------------------- ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 17:23 Message: Logged In: YES user_id=7887 Patch #1018386 was applied. Thanks for the report! And thanks again for the patch, Mike! ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-08-29 00:22 Message: Logged In: YES user_id=555 The particular problem with your test case turned out to be an infinite loop in the sre parser. This is fixed in patch #1018386. If you are aware of or encounter any other cases where sre's behavior deviates from pre, please post a bug for them. Pending that, I'd suggest this bug be closed. Thanks for your excellent bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776311&group_id=5470 From noreply at sourceforge.net Fri Sep 3 19:26:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 19:26:46 2004 Subject: [ python-Bugs-1018815 ] re.sub: two-digit group-reference hangs Message-ID: Bugs item #1018815, was opened at 2004-08-30 01:36 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Dyck (jmdyck) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.sub: two-digit group-reference hangs Initial Comment: Python 2.3.3 (#2, Feb 17 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 I think this affects 2.4 as well. If you invoke re.sub(), and the replacement contains a two-digit group-reference, it hangs. E.g. try print re.sub( r'(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)', r'\10', 'abcdefghijklm' ) Problem is infinite loop in sre_parse.py. I've attached a change that I think fixes it. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 17:26 Message: Logged In: YES user_id=7887 Patch #1018386 was applied, and really fixes this bug. Thanks folks! ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 11:44 Message: Logged In: YES user_id=38376 Assigning to Gustavo, who's reviewing #1018386 at the moment. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 11:38 Message: Logged In: YES user_id=38376 Still there in 2.4a3, it seems. ---------------------------------------------------------------------- Comment By: Michael Dyck (jmdyck) Date: 2004-08-30 01:45 Message: Logged In: YES user_id=663727 It sounds like this bug was fixed by patch 1018386 just yesterday! (Please check.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 From noreply at sourceforge.net Fri Sep 3 20:13:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 20:13:46 2004 Subject: [ python-Bugs-817234 ] re.finditer hangs on final empty match Message-ID: Bugs item #817234, was opened at 2003-10-03 15:01 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.finditer hangs on final empty match Initial Comment: The iterator returned by re.finditer appears to not terminate if the final match is empty, but rather keeps returning the final (empty) match. Is this a bug in _sre? If so, I'll be happy to file it, though fixing it is a bit beyond my _sre experience level at this point. The solution would appear to be to either a check for duplicate match in iterator.next(), or to increment position by one after returning an empty match (which should be OK, because if a non-empty match started at that location, we would have returned it instead of the empty match). Code to illustrate the failure: from re import finditer last = None for m in finditer( ".*", "asdf" ): if last == m.span(): print "duplicate match:", last break print m.group(), m.span() last = m.span() --- asdf (0, 4) (4, 4) duplicate match: (4, 4) --- findall works: print re.findall( ".*", "asdf" ) ['asdf', ''] Workaround is to explicitly check for a duplicate span, as I did above, or to check for a duplicate end(), which avoids the final empty match Seo Sanghyeon sent the following fix to python-dev list: Attached one line patch fixes re.finditer bug reported by Kevin J. Butler. I read cvs log to find out why this code is introduced, and it seems to be related to SF bug #581080. But that bug didn't appear after my patch, so I wonder why it was introduced in the first place. It seems beyond my understanding. Please enlighten me. To test: #581080 import re list(re.finditer('\s', 'a b')) # expected: one item list # bug: hang #Kevin J. Butler import re list(re.finditer('.*', 'asdf')) # expected: two item list (?) # bug: hang Seo Sanghyeon -------------- next part -------------- ? patch Index: Modules/_sre.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v retrieving revision 2.99 diff -c -r2.99 _sre.c *** Modules/_sre.c 26 Jun 2003 14:41:08 -0000 2.99 --- Modules/_sre.c 2 Oct 2003 03:48:55 -0000 *************** *** 3062,3069 **** match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if ((status == 0 || state->ptr == state->start) && ! state->ptr < state->end) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; --- 3062,3068 ---- match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if (status == 0 || state->ptr == state->start) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 18:13 Message: Logged In: YES user_id=7887 Patch applied and test cases added to check this bug and also for #581080. Kevin and Seo, thanks for the bug report and the fix. Fredrik, thanks for pointing me to the issue. Applied as: Lib/test/test_re.py: 1.52 Modules/_sre.c: 2.108 Patch attached for reference. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 12:04 Message: Logged In: YES user_id=38376 Still there in 2.4a3, as the following revised example shows: import re m = re.finditer(".*", "asdf") print m.next().span() print m.next().span() print m.next().span() # this should raise an exception Gustavo, can you look at this patch too? ---------------------------------------------------------------------- Comment By: Kevin J. Butler (kevinbutler) Date: 2003-10-03 18:16 Message: Logged In: YES user_id=117665 The above patch does resolve the problem. The code was introduced in rev 2.85 http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_sre.c to resolve bug 581080 http://sourceforge.net/tracker/index.php?func=detail&aid=581080&group_id=5470&atid=105470 but removing this line does not re-introduce that bug. Thanks, and kudos to Seo... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 From noreply at sourceforge.net Fri Sep 3 20:46:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 20:46:57 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-04 03:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Fri Sep 3 20:57:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 20:57:43 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 10:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) >Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Fri Sep 3 21:05:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 21:05:40 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-04 03:46 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Fri Sep 3 21:09:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 21:09:44 2004 Subject: [ python-Bugs-1022030 ] re.match(), re.MULTILINE and "^" broken Message-ID: Bugs item #1022030, was opened at 2004-09-03 19:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022030&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Notz (notz) Assigned to: Fredrik Lundh (effbot) Summary: re.match(), re.MULTILINE and "^" broken Initial Comment: The re.match() function does not appear to respect the re.MULTILINE flag when matching on "^". It does, however, behave as documented with respect to "$". I've observed this with Python 2.2.2 and 2.3.3 on Linux, RedHat 9.0. Below is some sample code and output that illustrates the issue. As illustrated, re.search() behaves as expected. $ cat /proc/version Linux version 2.4.20-28.9psycho (root@sahp5069) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Wed Feb 18 07: 08:55 MST 2004 $ python Python 2.2.2 (#1, Feb 10 2004, 13:57:46) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> $ python re_bug.py Pattern is '^hello world$' with flags = 10 Testing: "hello world thank you"... match_pass search_pass Testing: "ahem hello world"... match_fail search_pass Testing: "ahem hello world thank you"... match_fail search_pass I would expect the match to work (match_pass and search_pass) on all of the sample strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022030&group_id=5470 From noreply at sourceforge.net Fri Sep 3 21:10:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 21:11:00 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 10:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-03 14:10 Message: Logged In: YES user_id=80475 Fixed. See: LIb/random.py 1.66 Thanks for the prompt bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Fri Sep 3 23:34:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 23:34:23 2004 Subject: [ python-Bugs-1022030 ] re.match(), re.MULTILINE and "^" broken Message-ID: Bugs item #1022030, was opened at 2004-09-03 21:09 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022030&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Pat Notz (notz) Assigned to: Fredrik Lundh (effbot) Summary: re.match(), re.MULTILINE and "^" broken Initial Comment: The re.match() function does not appear to respect the re.MULTILINE flag when matching on "^". It does, however, behave as documented with respect to "$". I've observed this with Python 2.2.2 and 2.3.3 on Linux, RedHat 9.0. Below is some sample code and output that illustrates the issue. As illustrated, re.search() behaves as expected. $ cat /proc/version Linux version 2.4.20-28.9psycho (root@sahp5069) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Wed Feb 18 07: 08:55 MST 2004 $ python Python 2.2.2 (#1, Feb 10 2004, 13:57:46) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> $ python re_bug.py Pattern is '^hello world$' with flags = 10 Testing: "hello world thank you"... match_pass search_pass Testing: "ahem hello world"... match_fail search_pass Testing: "ahem hello world thank you"... match_fail search_pass I would expect the match to work (match_pass and search_pass) on all of the sample strings. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-09-03 23:34 Message: Logged In: YES user_id=38376 Match never scans the string: if something doesn't match at the beginning, it won't match at all. There's even a separate section in the documentation on re.match and ^: http://docs.python.org/lib/matching-searching.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022030&group_id=5470 From noreply at sourceforge.net Sat Sep 4 01:22:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 01:22:45 2004 Subject: [ python-Bugs-1022152 ] Bad examples of gettext.translation Message-ID: Bugs item #1022152, was opened at 2004-09-03 20:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022152&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Bad examples of gettext.translation Initial Comment: The usage examples on "6.27.3.3 Changing languages on the fly" (http://www.python.org/dev/doc/devel/lib/node293.html) are incorrect, because of the syntax of gettext.translation. The examples just don't match "6.27.2 Class-based API" (http://www.python.org/dev/doc/devel/lib/node285.html), and they gave me an error when tried them:the "domain" is not optional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022152&group_id=5470 From noreply at sourceforge.net Sat Sep 4 01:22:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 01:22:46 2004 Subject: [ python-Bugs-783990 ] test_re failure on 64bit targets (alpha, ia64) Message-ID: Bugs item #783990, was opened at 2003-08-06 02:17 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fredrik Lundh (effbot) Summary: test_re failure on 64bit targets (alpha, ia64) Initial Comment: test test_re failed -- Traceback (most recent call last): File "/home/doko/py/python2.3-2.3/Lib/test/test_re.py", line 283, in test_bigcharset u"\u2222").group(1), u"\u2222") AttributeError: 'NoneType' object has no attribute 'group' ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 18:22 Message: Logged In: YES user_id=555 This test 'test_re' doesn't fail for last night's snapshot, on Linux/ia64 or Linux/amd64. It also doesn't fail for python2.3 on Tru64. So probably this could be closed as 'fixed'. (Note, though, that the test 'test_bigcharset' doesn't really test re.UNICODE very well.) ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-08-06 02:18 Message: Logged In: YES user_id=60903 this should be alpha-linux, ia64-linux, didn't test any other OS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 From noreply at sourceforge.net Sat Sep 4 01:25:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 01:25:48 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-03 20:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 01:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Sat Sep 4 03:04:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 03:04:25 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-03 14:46 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-03 21:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-03 19:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Sat Sep 4 06:20:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 06:20:40 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-04 03:46 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2004-09-04 13:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 10:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 08:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Sat Sep 4 07:39:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 07:40:16 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Sat Sep 4 14:54:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 14:54:37 2004 Subject: [ python-Bugs-1022311 ] x, y in curses window object documentation Message-ID: Bugs item #1022311, was opened at 2004-09-04 14:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022311&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: x, y in curses window object documentation Initial Comment: lib/curses-window-objects.html says "x, y" several times for method parameters. I think this is wrong; it must be "y, x". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022311&group_id=5470 From noreply at sourceforge.net Sat Sep 4 18:47:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 18:47:52 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 12:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 18:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Sat Sep 4 18:48:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 18:48:41 2004 Subject: [ python-Bugs-1021596 ] Trivial fix for obscure bug in os.urandom() Message-ID: Bugs item #1021596, was opened at 2004-09-03 06:00 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021596&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Nick Mathewson (nickm) >Assigned to: Martin v. L?wis (loewis) Summary: Trivial fix for obscure bug in os.urandom() Initial Comment: The new os.urandom function checks for whether it has set _urandomfd with "if not _urandomfd:" . But this is incorrect; on some systems, if fd 0 has been closed, it is possible for _urandomfd to be 0. Instead, the check should be "if _urandomfd is None". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021596&group_id=5470 From noreply at sourceforge.net Sat Sep 4 18:52:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 18:52:11 2004 Subject: [ python-Bugs-1017450 ] including Python.h redefines _POSIX_C_SOURCE Message-ID: Bugs item #1017450, was opened at 2004-08-27 10:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017450&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jon K?re Hellan (jhellan) Assigned to: Nobody/Anonymous (nobody) Summary: including Python.h redefines _POSIX_C_SOURCE Initial Comment: Consider this program: #include #include int main (int arg, char **argv) { return 0; } We compile it like this cc -Wall -I/usr/include/python2.3 -c aa.c And get In file included from /usr/include/python2.3/Python.h:8, from aa.c:3: /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:122, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:11, from aa.c:2: /usr/include/features.h:171:1: warning: this is the location of the previous definition Python.h has redefind a symbol which got defined by including limits.h. This is unfriendly to programs which embed Python. I suspect that there are definitions in pyconfig.h which are only relevant when building the Python distribution. Such definitions should not be exposed to embedders or builders of 3rd party modules. I can make the warning go away by including Python.h first. But my application has its own config.h - strange that Python's has to go in front of it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 18:52 Message: Logged In: YES user_id=21627 Your program is in error - it must not include limits.h before including Python.h, see http://docs.python.org/api/includes.html The defines in Python.h *can* affect the code in the extension module, e.g. they might affect the size of off_t. Extensions which don't follow this rule may crash. ---------------------------------------------------------------------- Comment By: Jon K?re Hellan (jhellan) Date: 2004-08-27 10:56 Message: Logged In: YES user_id=268898 Sorry about the duplicate. That was my browser's "back" button. Platform is Debian sid (soon to be sarge), and Python version is 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017450&group_id=5470 From noreply at sourceforge.net Sat Sep 4 22:55:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 22:56:01 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 12:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific >Status: Open >Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 22:55 Message: Logged In: YES user_id=21627 In private email, Simon pointed out that there is a problem if Python is embedded and the embedded application simultaneously also invokes non-reentrant functions. I'm still uncertain whether that problem would be a bug in Python, and if it is, whether it is worthwhile getting fixed. OTOH, contributions would be certainly accepted. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 18:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Sun Sep 5 11:01:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 11:01:58 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-03 20:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 11:01 Message: Logged In: YES user_id=21627 Thanks for your report. I have re-rolled the package, and Anthony has made it available from http://www.python.org/ftp/python/2.4/python-2.4a3.2.msi I will commit the changes to msi.py shortly. I have left the Itanium installer untouched - Itanium users will either fix the extensions themselves, or wait for 2.4b1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-04 06:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 03:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 01:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Sun Sep 5 11:02:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 11:02:27 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-03 20:46 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 11:01 Message: Logged In: YES user_id=21627 Thanks for your report. I have re-rolled the package, and Anthony has made it available from http://www.python.org/ftp/python/2.4/python-2.4a3.2.msi I will commit the changes to msi.py shortly. I have left the Itanium installer untouched - Itanium users will either fix the extensions themselves, or wait for 2.4b1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-04 06:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 03:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 01:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Sun Sep 5 13:45:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 13:45:58 2004 Subject: [ python-Bugs-1020540 ] a wrong link from "frame object" in lib index Message-ID: Bugs item #1020540, was opened at 2004-09-01 11:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020540&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: a wrong link from "frame object" in lib index Initial Comment: a "frame object" link (in the library index: http://www.python.org/doc/current/lib/genindex.html) leads to "7.1 signal -- Set handlers for asynchronous events" page which seems wrong ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 06:45 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libsignal.tex 1.26 Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1020540&group_id=5470 From noreply at sourceforge.net Sun Sep 5 13:48:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 13:48:38 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 10:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 06:48 Message: Logged In: YES user_id=80475 Paul, Can you please verify that the attached files run on your system. TIA, Raymond ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-03 14:10 Message: Logged In: YES user_id=80475 Fixed. See: LIb/random.py 1.66 Thanks for the prompt bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Sun Sep 5 14:15:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 14:15:28 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 10:18 Message generated for change (Comment added) made by ssmmhh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 12:15 Message: Logged In: YES user_id=775521 Don't apply the patch - it's not tested, but just serves as an example, and it's certainly not complete. For some _r functions it's quite obvious how they should be used. For ones with variable-length buffers accompanying the struct to be filled in it's not clear how they should be sized. It's also not clear whether the ERANGE return should be used to 'automatically' realloc a larger buffer, or whether the ERANGE error should simply be passed back to Python as a general failure. For some buffers (asctime_r) the maximum size can be guessed based on common sense, for others, defines exist in system headers which may not be portable, requiring possible further configure checks. I think the way I would fix this is to introduce a wrapper for each reentrant function that returns a malloc'ed buffer that must be freed by the caller when done with the structure. The wrapper would continually allocate larger buffers until the size was correct. Alteratively, one might argue I'm being overly paranoid, and that for each function we should be able to guess a sensible buffer length, then just fail if the api call returns too much data. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 20:55 Message: Logged In: YES user_id=21627 In private email, Simon pointed out that there is a problem if Python is embedded and the embedded application simultaneously also invokes non-reentrant functions. I'm still uncertain whether that problem would be a bug in Python, and if it is, whether it is worthwhile getting fixed. OTOH, contributions would be certainly accepted. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 16:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Sun Sep 5 18:23:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 18:23:08 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 12:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 18:23 Message: Logged In: YES user_id=21627 The patch looks good. It doesn't need to be complete, but it should be correct for the APIs which it does change. A few comments: - there is probably little point in changing getaddrinfo.c. This is an emulation that is only used on systems which don't have a "proper" getaddrinfo, and most likely, all systems offering gethostbyname_r also offer getaddrinfo. - the usage of readdir_r is incorrect - you need to provide for sufficient space. - I don't think it is good to allocate 8k on the stack. Instead, you should indeed start with a small buffer, then grow it as needed, using malloc. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 14:15 Message: Logged In: YES user_id=775521 Don't apply the patch - it's not tested, but just serves as an example, and it's certainly not complete. For some _r functions it's quite obvious how they should be used. For ones with variable-length buffers accompanying the struct to be filled in it's not clear how they should be sized. It's also not clear whether the ERANGE return should be used to 'automatically' realloc a larger buffer, or whether the ERANGE error should simply be passed back to Python as a general failure. For some buffers (asctime_r) the maximum size can be guessed based on common sense, for others, defines exist in system headers which may not be portable, requiring possible further configure checks. I think the way I would fix this is to introduce a wrapper for each reentrant function that returns a malloc'ed buffer that must be freed by the caller when done with the structure. The wrapper would continually allocate larger buffers until the size was correct. Alteratively, one might argue I'm being overly paranoid, and that for each function we should be able to guess a sensible buffer length, then just fail if the api call returns too much data. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 22:55 Message: Logged In: YES user_id=21627 In private email, Simon pointed out that there is a problem if Python is embedded and the embedded application simultaneously also invokes non-reentrant functions. I'm still uncertain whether that problem would be a bug in Python, and if it is, whether it is worthwhile getting fixed. OTOH, contributions would be certainly accepted. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 18:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Sun Sep 5 19:39:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 19:40:42 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Sun Sep 5 21:53:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 21:53:57 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-17 18:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open >Resolution: None Priority: 3 Submitted By: Amit Aronovitch (amitar) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-05 12:53 Message: Logged In: YES user_id=357491 Reassigning to Johannes since he has checkin rights now. =) But honestly I think this bug is just not worth the hassle. This is only an issue if you are futzing with your file system in an uncommon way. 'help' is just for quick checks and thus if doesn't work for *every* situation it isn't going to be the end of the world. Plus I don't like how the patch touches so many files with the same chunk of code. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-08-29 06:02 Message: Logged In: YES user_id=564711 Pls see attached files. Note that jlgijsbers' patch does not resolve the full scope of the problem as described in my original post (see the "discussion" part) - namely: it only works for symbolic links. bcannon (re 12/7 msg): Sorry. I wrote the long explanations in hope it would save you time, but it seems they were not clear enough. To avoid trouble repeating the problem, this time I'll provide a shell script for testing it. Also provided is a proposed patch (against cvs snapshot from 29 Aug 2004). About the patch ----------------- I added a "fileid" function to os.path (as suggested in my original post). This means macpath os2emxpath and ntpath had to be touched as well as posixpath. (libposixpath.tex would also need an update if you decide to adopt this patch) Question about inspect.getabsfile ----------------------------------- I'm not sure if this function is ment to be an "internal use" or "interface" function. It does not appear in the module's documentation (libinspect.tex), but the pydoc module still uses it (and as far as I could see - it's the only module that uses it). After my patch, getabsfile is not used internally by inspect anymore, so should be deleted if "internal use". The use of this function in pydoc is for human readable output, so I don't think it's really necessary there (I think there's no need to do "normcase" there). tks for yr attention ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 11:47 Message: Logged In: YES user_id=357491 Checked in as rev. 1.52 for 'inspect'. Not going to backport since it is a semantic change. Thanks for the patch, Johannes. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 10:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-12 17:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-12 15:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 11:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 13:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Sun Sep 5 22:07:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 22:07:53 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 10:18 Message generated for change (Comment added) made by ssmmhh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 20:07 Message: Logged In: YES user_id=775521 Point taken about readdir_r and getaddrinfo. I'll submit something more robust (and tested) probably next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 16:23 Message: Logged In: YES user_id=21627 The patch looks good. It doesn't need to be complete, but it should be correct for the APIs which it does change. A few comments: - there is probably little point in changing getaddrinfo.c. This is an emulation that is only used on systems which don't have a "proper" getaddrinfo, and most likely, all systems offering gethostbyname_r also offer getaddrinfo. - the usage of readdir_r is incorrect - you need to provide for sufficient space. - I don't think it is good to allocate 8k on the stack. Instead, you should indeed start with a small buffer, then grow it as needed, using malloc. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 12:15 Message: Logged In: YES user_id=775521 Don't apply the patch - it's not tested, but just serves as an example, and it's certainly not complete. For some _r functions it's quite obvious how they should be used. For ones with variable-length buffers accompanying the struct to be filled in it's not clear how they should be sized. It's also not clear whether the ERANGE return should be used to 'automatically' realloc a larger buffer, or whether the ERANGE error should simply be passed back to Python as a general failure. For some buffers (asctime_r) the maximum size can be guessed based on common sense, for others, defines exist in system headers which may not be portable, requiring possible further configure checks. I think the way I would fix this is to introduce a wrapper for each reentrant function that returns a malloc'ed buffer that must be freed by the caller when done with the structure. The wrapper would continually allocate larger buffers until the size was correct. Alteratively, one might argue I'm being overly paranoid, and that for each function we should be able to guess a sensible buffer length, then just fail if the api call returns too much data. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 20:55 Message: Logged In: YES user_id=21627 In private email, Simon pointed out that there is a problem if Python is embedded and the embedded application simultaneously also invokes non-reentrant functions. I'm still uncertain whether that problem would be a bug in Python, and if it is, whether it is worthwhile getting fixed. OTOH, contributions would be certainly accepted. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 16:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Sun Sep 5 22:10:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 22:10:24 2004 Subject: [ python-Bugs-1019048 ] __metaclass__ in locals is ignored Message-ID: Bugs item #1019048, was opened at 2004-08-30 05:52 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019048&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: __metaclass__ in locals is ignored Initial Comment: The local namespace is not checked for a __metaclass__ when constructing a new class. This may be consistent with a strict reading of the language standard [http://docs.python.org/ref/metaclasses.html#l2h-216] but it's surprising. I think that the lookup for __metaclass__ should proceed in the same way as any other name lookup (after it is not found in the namespace of the class-to-be), which would include a lookup in the local namespace. The attached file should print "metaclass called with ..." and "C constructed as None..." but it doesn't in the "local case" If this behavior is not a bug, would a doc patch emphasizing the non-lookup in locals be accepted? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-05 13:10 Message: Logged In: YES user_id=357491 It's not a bug. If you wanted your little class to have a metaclass it should have been defined in a __metaclass__ attribute. The whole global __metaclass__ thing in the global namespace is just a helper situation when you want all code to have the same metaclass, but also just to move old code over to new-style. It is still better practice to list the metaclass explicitly in the class. As for a patch about locals, I don't think it is needed since it is fairly explicit about what cases lead to a metaclass being used. Always go with a strict reading of the docs. I wouldn't mind seeing a patch that clarified the first bullet point about ``dict[__metaclass__]`` and a line saying that specifying it as a class attribute is the best practice, though. But that should be a separate patch and not tied to this bug report which I am closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019048&group_id=5470 From noreply at sourceforge.net Mon Sep 6 02:10:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 02:10:27 2004 Subject: [ python-Bugs-1022813 ] test_xrange fails on osf1 v5.1b Message-ID: Bugs item #1022813, was opened at 2004-09-06 12:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022813&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: roadkill (dharma_roadkill) Assigned to: Nobody/Anonymous (nobody) Summary: test_xrange fails on osf1 v5.1b Initial Comment: On a build of Python 2.4a3: uname -a: OSF1 xxx.tnzi.com V5.1 2650 alpha alpha > ./python ./Lib/test/test_xrange.py test_xrange (__main__.XrangeTest) ... ERROR ========================================== ============================ ERROR: test_xrange (__main__.XrangeTest) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 56, in test_xrange self.assertEqual(len(xrange(-sys.maxint, sys.maxint, 2)), ValueError: xrange object size cannot be reported ------------------------------------------------------ ---------------- Ran 1 test in 0.001s FAILED (errors=1) Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 64, in ? test_main() File "./Lib/test/test_xrange.py", line 61, in test_main test.test_support.run_unittest(XrangeTest) File "/u03/home/doug/python/Python- 2.4a3/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/u03/home/doug/python/Python- 2.4a3/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 56, in test_xrange self.assertEqual(len(xrange(-sys.maxint, sys.maxint, 2)), ValueError: xrange object size cannot be reported Everything else seems to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022813&group_id=5470 From noreply at sourceforge.net Mon Sep 6 02:17:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 02:17:30 2004 Subject: [ python-Bugs-901654 ] split method documentation can be improved Message-ID: Bugs item #901654, was opened at 2004-02-21 04:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901654&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Raymond Hettinger (rhettinger) Summary: split method documentation can be improved Initial Comment: If you compare the documentation for the string.split function and the split method on strings, you'll find the former much clearer in the description of what happens with a None separator argument. The doc strings of both are like the method, not terribly precise. It may be worth it to compare other string methods / string module functions. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 19:17 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libstdtypes.tex 1.164 Leaving the doc strings as is. While not very precise, they don't really warrant all the detail included in the main docs. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-21 19:13 Message: Logged In: YES user_id=671362 This one is related to bug # 811604. "string".split behaviour for empty strings http://www.python.org/sf/811604 I think the doc change will also close the bug #811604. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901654&group_id=5470 From noreply at sourceforge.net Mon Sep 6 02:36:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 02:36:57 2004 Subject: [ python-Bugs-1022813 ] test_xrange fails on osf1 v5.1b Message-ID: Bugs item #1022813, was opened at 2004-09-05 19:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022813&group_id=5470 >Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Nobody/Anonymous (nobody) Summary: test_xrange fails on osf1 v5.1b Initial Comment: On a build of Python 2.4a3: uname -a: OSF1 xxx.tnzi.com V5.1 2650 alpha alpha > ./python ./Lib/test/test_xrange.py test_xrange (__main__.XrangeTest) ... ERROR ========================================== ============================ ERROR: test_xrange (__main__.XrangeTest) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 56, in test_xrange self.assertEqual(len(xrange(-sys.maxint, sys.maxint, 2)), ValueError: xrange object size cannot be reported ------------------------------------------------------ ---------------- Ran 1 test in 0.001s FAILED (errors=1) Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 64, in ? test_main() File "./Lib/test/test_xrange.py", line 61, in test_main test.test_support.run_unittest(XrangeTest) File "/u03/home/doug/python/Python- 2.4a3/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/u03/home/doug/python/Python- 2.4a3/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 56, in test_xrange self.assertEqual(len(xrange(-sys.maxint, sys.maxint, 2)), ValueError: xrange object size cannot be reported Everything else seems to work. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 19:36 Message: Logged In: YES user_id=80475 I haven't looked into a solution yet but want to record what I've found so far. In checkin 2.44 on 9/11/2002, guido noted, """ Untested code for 64-bit platforms. range_length() is declared as int but returns r->len which is a long. This doesn't even cause a warning on 32-bit platforms, but can return bogus values on 64-bit platforms (and should cause a compiler warning). Fix this by inserting a range check when LONG_MAX != INT_MAX, and adding an explicit cast to (int) when the test passes. When r->len is out of range, PySequence_Size() and hence len() will report an error (but an iterator will still work). """ The code for the check is: static int range_length(rangeobject *r) { #if LONG_MAX != INT_MAX if (r->len > INT_MAX) { PyErr_SetString(PyExc_ValueError, "xrange object size cannot be reported"); return -1; } #endif return (int)(r->len); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022813&group_id=5470 From noreply at sourceforge.net Mon Sep 6 06:45:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 06:46:00 2004 Subject: [ python-Bugs-1022880 ] random.shuffle should restrict the type of its argument Message-ID: Bugs item #1022880, was opened at 2004-09-06 04:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: random.shuffle should restrict the type of its argument Initial Comment: Consider the following ******************************************** In [1]: foo = numstr.array(['a', 'c'], shape=(2,1)) In [2]: import random In [3]: import numarray.strings as numstr In [4]: foo Out[4]: CharArray([['a'], ['c']]) In [5]: random.shuffle(foo) In [6]: foo Out[64]: CharArray([['a'], ['a']]) ********************************************** The documentation says that shuffle takes a list as argument. In this case it accepts a Numarray character array without complaint and returns gibberish. I think there should be some restrictions on what arguments are accepted. Thanks. Faheem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 From noreply at sourceforge.net Mon Sep 6 07:16:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 07:16:40 2004 Subject: [ python-Bugs-1022880 ] random.shuffle should restrict the type of its argument Message-ID: Bugs item #1022880, was opened at 2004-09-05 23:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: random.shuffle should restrict the type of its argument Initial Comment: Consider the following ******************************************** In [1]: foo = numstr.array(['a', 'c'], shape=(2,1)) In [2]: import random In [3]: import numarray.strings as numstr In [4]: foo Out[4]: CharArray([['a'], ['c']]) In [5]: random.shuffle(foo) In [6]: foo Out[64]: CharArray([['a'], ['a']]) ********************************************** The documentation says that shuffle takes a list as argument. In this case it accepts a Numarray character array without complaint and returns gibberish. I think there should be some restrictions on what arguments are accepted. Thanks. Faheem. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 00:16 Message: Logged In: YES user_id=80475 While in your case it worked out badly, python's duck typing is a core design principle. It is a feature that mutable sequences (listlike objects) can be passed as arguments and shuffle does the riight thing. It is unfornate that the 2D arrays look like lists (having __len__, __getitem__, and __setitem__) but behave in ways that are unlike other sequences. For your use case, first flatten the array and then shuffle it: x = foo.tolist() shuffle(x) So, this is not a bug but I'm leaving it open for a bit in case others want to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 From noreply at sourceforge.net Mon Sep 6 08:14:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 08:14:24 2004 Subject: [ python-Bugs-1022880 ] random.shuffle should restrict the type of its argument Message-ID: Bugs item #1022880, was opened at 2004-09-06 04:45 Message generated for change (Comment added) made by fmitha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: random.shuffle should restrict the type of its argument Initial Comment: Consider the following ******************************************** In [1]: foo = numstr.array(['a', 'c'], shape=(2,1)) In [2]: import random In [3]: import numarray.strings as numstr In [4]: foo Out[4]: CharArray([['a'], ['c']]) In [5]: random.shuffle(foo) In [6]: foo Out[64]: CharArray([['a'], ['a']]) ********************************************** The documentation says that shuffle takes a list as argument. In this case it accepts a Numarray character array without complaint and returns gibberish. I think there should be some restrictions on what arguments are accepted. Thanks. Faheem. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 06:14 Message: Logged In: YES user_id=1063525 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 05:16 Message: Logged In: YES user_id=80475 While in your case it worked out badly, python's duck typing is a core design principle. It is a feature that mutable sequences (listlike objects) can be passed as arguments and shuffle does the riight thing. It is unfornate that the 2D arrays look like lists (having __len__, __getitem__, and __setitem__) but behave in ways that are unlike other sequences. For your use case, first flatten the array and then shuffle it: x = foo.tolist() shuffle(x) So, this is not a bug but I'm leaving it open for a bit in case others want to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 From noreply at sourceforge.net Mon Sep 6 08:18:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 08:18:15 2004 Subject: [ python-Bugs-1022880 ] random.shuffle should restrict the type of its argument Message-ID: Bugs item #1022880, was opened at 2004-09-06 04:45 Message generated for change (Comment added) made by fmitha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: random.shuffle should restrict the type of its argument Initial Comment: Consider the following ******************************************** In [1]: foo = numstr.array(['a', 'c'], shape=(2,1)) In [2]: import random In [3]: import numarray.strings as numstr In [4]: foo Out[4]: CharArray([['a'], ['c']]) In [5]: random.shuffle(foo) In [6]: foo Out[64]: CharArray([['a'], ['a']]) ********************************************** The documentation says that shuffle takes a list as argument. In this case it accepts a Numarray character array without complaint and returns gibberish. I think there should be some restrictions on what arguments are accepted. Thanks. Faheem. ---------------------------------------------------------------------- >Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 06:18 Message: Logged In: YES user_id=1063525 >> Comment By: Raymond Hettinger (rhettinger) > Date: 2004-09-06 00:16 > > Message: > Logged In: YES > user_id=80475 > > While in your case it worked out badly, python's duck typing > is a core design principle. It is a feature that mutable > sequences (listlike objects) can be passed as arguments and > shuffle does the riight thing. Yes, but in this case, it does not do the right thing. > It is unfornate that the 2D arrays look like lists (having > __len__, __getitem__, and __setitem__) but behave in ways > that are unlike other sequences. For your use case, first > flatten the array and then shuffle it: > x = foo.tolist() > shuffle(x) Yes, that is what I did. > So, this is not a bug but I'm leaving it open for a bit in > case others want to comment. Faheem. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 06:14 Message: Logged In: YES user_id=1063525 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 05:16 Message: Logged In: YES user_id=80475 While in your case it worked out badly, python's duck typing is a core design principle. It is a feature that mutable sequences (listlike objects) can be passed as arguments and shuffle does the riight thing. It is unfornate that the 2D arrays look like lists (having __len__, __getitem__, and __setitem__) but behave in ways that are unlike other sequences. For your use case, first flatten the array and then shuffle it: x = foo.tolist() shuffle(x) So, this is not a bug but I'm leaving it open for a bit in case others want to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 From noreply at sourceforge.net Mon Sep 6 09:10:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 09:10:05 2004 Subject: [ python-Bugs-1022880 ] random.shuffle should restrict the type of its argument Message-ID: Bugs item #1022880, was opened at 2004-09-05 23:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: random.shuffle should restrict the type of its argument Initial Comment: Consider the following ******************************************** In [1]: foo = numstr.array(['a', 'c'], shape=(2,1)) In [2]: import random In [3]: import numarray.strings as numstr In [4]: foo Out[4]: CharArray([['a'], ['c']]) In [5]: random.shuffle(foo) In [6]: foo Out[64]: CharArray([['a'], ['a']]) ********************************************** The documentation says that shuffle takes a list as argument. In this case it accepts a Numarray character array without complaint and returns gibberish. I think there should be some restrictions on what arguments are accepted. Thanks. Faheem. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 02:10 Message: Logged In: YES user_id=80475 I don't see a way to detect your issue without breaking shufflle's current capability of working with a variety of mutable sequences. Changing that would likely break code that is currently working fine. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 01:18 Message: Logged In: YES user_id=1063525 >> Comment By: Raymond Hettinger (rhettinger) > Date: 2004-09-06 00:16 > > Message: > Logged In: YES > user_id=80475 > > While in your case it worked out badly, python's duck typing > is a core design principle. It is a feature that mutable > sequences (listlike objects) can be passed as arguments and > shuffle does the riight thing. Yes, but in this case, it does not do the right thing. > It is unfornate that the 2D arrays look like lists (having > __len__, __getitem__, and __setitem__) but behave in ways > that are unlike other sequences. For your use case, first > flatten the array and then shuffle it: > x = foo.tolist() > shuffle(x) Yes, that is what I did. > So, this is not a bug but I'm leaving it open for a bit in > case others want to comment. Faheem. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 01:14 Message: Logged In: YES user_id=1063525 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 00:16 Message: Logged In: YES user_id=80475 While in your case it worked out badly, python's duck typing is a core design principle. It is a feature that mutable sequences (listlike objects) can be passed as arguments and shuffle does the riight thing. It is unfornate that the 2D arrays look like lists (having __len__, __getitem__, and __setitem__) but behave in ways that are unlike other sequences. For your use case, first flatten the array and then shuffle it: x = foo.tolist() shuffle(x) So, this is not a bug but I'm leaving it open for a bit in case others want to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 From noreply at sourceforge.net Mon Sep 6 09:19:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 09:19:38 2004 Subject: [ python-Bugs-1022912 ] Generator exps fail with large value of range Message-ID: Bugs item #1022912, was opened at 2004-09-06 19:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022912&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andy Elvey (mr_moose) Assigned to: Nobody/Anonymous (nobody) Summary: Generator exps fail with large value of range Initial Comment: My platform - Mepis Linux, kernel 2.6.4 , Pentium III I tested generator expressions by using the following statement (which finds the sum of a range of numbers) - sum(a for a in range(1, 123)) As can be seen in the output below, this works fine for small values of a. However, it gives an OverflowError for large values of a. ********* Start of output ******************************************* Python 2.4a3 (#1, Sep 5 2004, 15:03:34) [GCC 3.3.3 (Debian 20040429)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> sum(a for a in range(1, 123)) 7503 >>> sum(a for a in range(1, 999999999999999)) Traceback (most recent call last): File "", line 1, in ? OverflowError: range() result has too many items >>> *********** End of output ********************************************* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022912&group_id=5470 From noreply at sourceforge.net Mon Sep 6 09:25:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 09:25:27 2004 Subject: [ python-Bugs-1022912 ] Generator exps fail with large value of range Message-ID: Bugs item #1022912, was opened at 2004-09-06 02:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022912&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andy Elvey (mr_moose) Assigned to: Nobody/Anonymous (nobody) Summary: Generator exps fail with large value of range Initial Comment: My platform - Mepis Linux, kernel 2.6.4 , Pentium III I tested generator expressions by using the following statement (which finds the sum of a range of numbers) - sum(a for a in range(1, 123)) As can be seen in the output below, this works fine for small values of a. However, it gives an OverflowError for large values of a. ********* Start of output ******************************************* Python 2.4a3 (#1, Sep 5 2004, 15:03:34) [GCC 3.3.3 (Debian 20040429)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> sum(a for a in range(1, 123)) 7503 >>> sum(a for a in range(1, 999999999999999)) Traceback (most recent call last): File "", line 1, in ? OverflowError: range() result has too many items >>> *********** End of output ********************************************* ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 02:25 Message: Logged In: YES user_id=80475 That is an error message from range(), not from genexps. To see that, try range(9999999999999) by itself. Even if range could process numbers that big, you wouldn't have enough memory to holding the resulting list. For what you're trying to do, use xrange() to save memory. Also remember that using large numbers will result in that many iterations. If the number is too large, you may grow old before the computation completes ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022912&group_id=5470 From noreply at sourceforge.net Mon Sep 6 10:57:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 10:57:44 2004 Subject: [ python-Bugs-1022951 ] make test fails on HP-UX11i Message-ID: Bugs item #1022951, was opened at 2004-09-06 09:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: make test fails on HP-UX11i Initial Comment: Built Python-2.4a3 on HP-UX11i. When running make test, I get the following error: running build_scripts ./python -E -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"- "+sys.version[0:3]' >platform find ./Lib -name '*.py[co]' -print | xargs rm -f ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 (ignored) ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 From noreply at sourceforge.net Mon Sep 6 10:59:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 10:59:53 2004 Subject: [ python-Bugs-1022953 ] binascii.a2b_hqx("") raises SystemError Message-ID: Bugs item #1022953, was opened at 2004-09-06 08:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Florian Bauer (bauflo3) Assigned to: Nobody/Anonymous (nobody) Summary: binascii.a2b_hqx("") raises SystemError Initial Comment: I noticed the following on Python 2.2, Python 2.3 and Python 2.4a1 with the Windows builds on WinXP and Win2000: >>> import binascii >>> binascii.a2b_hqx("") Traceback (most recent call last): File "", line 1, in -toplevel- binascii.a2b_hqx("") SystemError: C:\sf\python\dist23 \src\Objects\stringobject.c:3316: bad argument to internal function The empty string is probably wrong input to a2b_hqx, but I think it should raise a ValueError at most, not a SystemError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 From noreply at sourceforge.net Mon Sep 6 11:55:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 11:55:11 2004 Subject: [ python-Bugs-1022951 ] make test fails on HP-UX11i Message-ID: Bugs item #1022951, was opened at 2004-09-06 09:57 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: make test fails on HP-UX11i Initial Comment: Built Python-2.4a3 on HP-UX11i. When running make test, I get the following error: running build_scripts ./python -E -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"- "+sys.version[0:3]' >platform find ./Lib -name '*.py[co]' -print | xargs rm -f ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 (ignored) ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2004-09-06 10:55 Message: Logged In: YES user_id=200117 Sorry, I should have read the bugs page first! Please disregard this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 From noreply at sourceforge.net Mon Sep 6 17:11:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 17:11:31 2004 Subject: [ python-Bugs-1022953 ] binascii.a2b_hqx("") raises SystemError Message-ID: Bugs item #1022953, was opened at 2004-09-06 03:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Florian Bauer (bauflo3) >Assigned to: Raymond Hettinger (rhettinger) Summary: binascii.a2b_hqx("") raises SystemError Initial Comment: I noticed the following on Python 2.2, Python 2.3 and Python 2.4a1 with the Windows builds on WinXP and Win2000: >>> import binascii >>> binascii.a2b_hqx("") Traceback (most recent call last): File "", line 1, in -toplevel- binascii.a2b_hqx("") SystemError: C:\sf\python\dist23 \src\Objects\stringobject.c:3316: bad argument to internal function The empty string is probably wrong input to a2b_hqx, but I think it should raise a ValueError at most, not a SystemError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 From noreply at sourceforge.net Mon Sep 6 17:13:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 17:13:56 2004 Subject: [ python-Bugs-1022951 ] make test fails on HP-UX11i Message-ID: Bugs item #1022951, was opened at 2004-09-06 03:57 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: make test fails on HP-UX11i Initial Comment: Built Python-2.4a3 on HP-UX11i. When running make test, I get the following error: running build_scripts ./python -E -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"- "+sys.version[0:3]' >platform find ./Lib -name '*.py[co]' -print | xargs rm -f ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 (ignored) ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-09-06 04:55 Message: Logged In: YES user_id=200117 Sorry, I should have read the bugs page first! Please disregard this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 From noreply at sourceforge.net Mon Sep 6 17:33:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 17:33:53 2004 Subject: [ python-Bugs-1022953 ] binascii.a2b_hqx("") raises SystemError Message-ID: Bugs item #1022953, was opened at 2004-09-06 03:59 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Florian Bauer (bauflo3) >Assigned to: Nobody/Anonymous (nobody) Summary: binascii.a2b_hqx("") raises SystemError Initial Comment: I noticed the following on Python 2.2, Python 2.3 and Python 2.4a1 with the Windows builds on WinXP and Win2000: >>> import binascii >>> binascii.a2b_hqx("") Traceback (most recent call last): File "", line 1, in -toplevel- binascii.a2b_hqx("") SystemError: C:\sf\python\dist23 \src\Objects\stringobject.c:3316: bad argument to internal function The empty string is probably wrong input to a2b_hqx, but I think it should raise a ValueError at most, not a SystemError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 From noreply at sourceforge.net Mon Sep 6 21:03:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 21:03:51 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 12:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Mon Sep 6 21:35:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 21:36:04 2004 Subject: [ python-Bugs-1014022 ] mimetypes add_type has bogus self parameter Message-ID: Bugs item #1014022, was opened at 2004-08-23 03:39 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Cliff Wells (cliffwells18) Assigned to: Walter D?rwald (doerwalter) Summary: mimetypes add_type has bogus self parameter Initial Comment: Python 2.3.3 mimetypes module defines the following function: def add_type(self, type, ext, strict=True) This is incorrect as there should be no "self" argument. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-09-06 21:35 Message: Logged In: YES user_id=89016 Closing the bug as "out of date". If this is still an issue, please feel free to reopen it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-23 10:15 Message: Logged In: YES user_id=89016 The problem with the bogus self parameter has already been fixed in CVS (both on the trunk (revision 1.30) and on the maintainance branch (revision 1.28.8.2 which went into release 2.3.4). The global add_type() *does* call init(). Can you check whether your problem is gone with 2.3.4? ---------------------------------------------------------------------- Comment By: Cliff Wells (cliffwells18) Date: 2004-08-23 03:48 Message: Logged In: YES user_id=340357 Actually, the real problem appears to be that mimetypes.init() isn't called automatically as the documentation suggests. import mimetypes mimetypes.add_type('text/xml', '.rss') doesn't work but import mimetypes mimetypes.init() mimetypes.add_type('text/xml', '.rss') does. From http://www.python.org/doc/current/lib/module-mimetypes.html: "The functions described below provide the primary interface for this module. If the module has not been initialized, they will call init() if they rely on the information init() sets up." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 From noreply at sourceforge.net Mon Sep 6 22:26:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 22:27:05 2004 Subject: [ python-Bugs-1022953 ] binascii.a2b_hqx("") raises SystemError Message-ID: Bugs item #1022953, was opened at 2004-09-06 03:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Florian Bauer (bauflo3) >Assigned to: Raymond Hettinger (rhettinger) Summary: binascii.a2b_hqx("") raises SystemError Initial Comment: I noticed the following on Python 2.2, Python 2.3 and Python 2.4a1 with the Windows builds on WinXP and Win2000: >>> import binascii >>> binascii.a2b_hqx("") Traceback (most recent call last): File "", line 1, in -toplevel- binascii.a2b_hqx("") SystemError: C:\sf\python\dist23 \src\Objects\stringobject.c:3316: bad argument to internal function The empty string is probably wrong input to a2b_hqx, but I think it should raise a ValueError at most, not a SystemError. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:26 Message: Logged In: YES user_id=80475 Working on it. The same error also occurs with a2b_hqx, b2a_uu, b2a_hqx, and rlecode_hqx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 From noreply at sourceforge.net Mon Sep 6 22:42:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 22:42:13 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Mon Sep 6 23:14:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 23:14:27 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-18 04:24 Message generated for change (Comment added) made by amitar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Amit Aronovitch (amitar) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Amit Aronovitch (amitar) Date: 2004-09-07 00:14 Message: Logged In: YES user_id=564711 Your'e the maintainers. I'll have to live with whatever you decide, but I still feel I must bring my knowledge/arguments to your attention. Basicly, i believe that providing an os.path.fileid function is more "correct" conceptually as opposed to 'realpath' (have a look at the implementation of the 'samefile' function in the pre-my-patch version of posixpath.py - shouldn't this be generalizable?), so would probably be more resistant to future bugs. (The specific problem that made me notice this bug would probably be solved by Johannes' patch, but problems could appear elsewhere for other people.) re: "... filesystem in an uncommon way" - a) You may still want to use python on systems where you dont have much control over the way your sysadmin organises the filesystem. b) Some systems have complex multi-platform network filesystems. Different platforms share the crossplatform files of the installation. It becomes necessary to use links to keep it managable (though I believe symlinks should almost always be enough). re: "'help' is just..." - Well, as I said before, the problem is really with *inspect*. This is a rather general purpose module, and bad things might happen if you get this unexpected 'None' output from inspect.getmodule re: "... the patch touches so many files" - This is the nature of the current os.path implementation. The common interface is reimplemented for each platform. For example, the "realpath" function has a default no-op implementation, which is repeated in many of the *path.py (p.s., I believe the 'realpath' function was added because people actually needed something like my fileid function, but missed the generalization - unique ID does not always have to be a PATH). I could have provided a default in the common os.py code, but decided this kind of implementation would be inconsistent with current module's style. If you think otherwise - I can provide such alternative. p.s. - I would appreciate a reply about my 'inspect.getabsfile' question - I believe functions should either be documented or used only internally (otherwise you can't change internal implementation without breaking external code). p.s. 2 - I'm uploading an up-to-date diff p.s. 3 - If you think this kind of conversation is inappropriate for the bts - pls let me know - you can use personal email. tks ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-05 22:53 Message: Logged In: YES user_id=357491 Reassigning to Johannes since he has checkin rights now. =) But honestly I think this bug is just not worth the hassle. This is only an issue if you are futzing with your file system in an uncommon way. 'help' is just for quick checks and thus if doesn't work for *every* situation it isn't going to be the end of the world. Plus I don't like how the patch touches so many files with the same chunk of code. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-08-29 16:02 Message: Logged In: YES user_id=564711 Pls see attached files. Note that jlgijsbers' patch does not resolve the full scope of the problem as described in my original post (see the "discussion" part) - namely: it only works for symbolic links. bcannon (re 12/7 msg): Sorry. I wrote the long explanations in hope it would save you time, but it seems they were not clear enough. To avoid trouble repeating the problem, this time I'll provide a shell script for testing it. Also provided is a proposed patch (against cvs snapshot from 29 Aug 2004). About the patch ----------------- I added a "fileid" function to os.path (as suggested in my original post). This means macpath os2emxpath and ntpath had to be touched as well as posixpath. (libposixpath.tex would also need an update if you decide to adopt this patch) Question about inspect.getabsfile ----------------------------------- I'm not sure if this function is ment to be an "internal use" or "interface" function. It does not appear in the module's documentation (libinspect.tex), but the pydoc module still uses it (and as far as I could see - it's the only module that uses it). After my patch, getabsfile is not used internally by inspect anymore, so should be deleted if "internal use". The use of this function in pydoc is for human readable output, so I don't think it's really necessary there (I think there's no need to do "normcase" there). tks for yr attention ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 21:47 Message: Logged In: YES user_id=357491 Checked in as rev. 1.52 for 'inspect'. Not going to backport since it is a semantic change. Thanks for the patch, Johannes. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 20:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-13 03:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-13 01:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 21:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 23:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 05:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Tue Sep 7 00:34:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 00:34:09 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 15:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Raymond Hettinger (rhettinger) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Tue Sep 7 00:59:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 01:00:15 2004 Subject: [ python-Bugs-1022953 ] binascii.a2b_hqx("") raises SystemError Message-ID: Bugs item #1022953, was opened at 2004-09-06 03:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Florian Bauer (bauflo3) Assigned to: Raymond Hettinger (rhettinger) Summary: binascii.a2b_hqx("") raises SystemError Initial Comment: I noticed the following on Python 2.2, Python 2.3 and Python 2.4a1 with the Windows builds on WinXP and Win2000: >>> import binascii >>> binascii.a2b_hqx("") Traceback (most recent call last): File "", line 1, in -toplevel- binascii.a2b_hqx("") SystemError: C:\sf\python\dist23 \src\Objects\stringobject.c:3316: bad argument to internal function The empty string is probably wrong input to a2b_hqx, but I think it should raise a ValueError at most, not a SystemError. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:59 Message: Logged In: YES user_id=80475 Fixed. See: Modules/binascii.c 2.43 Lib/test/test_binascii.py 1.16 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:26 Message: Logged In: YES user_id=80475 Working on it. The same error also occurs with a2b_hqx, b2a_uu, b2a_hqx, and rlecode_hqx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022953&group_id=5470 From noreply at sourceforge.net Tue Sep 7 01:43:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 01:43:15 2004 Subject: [ python-Bugs-1023359 ] Example does not match diagram. Message-ID: Bugs item #1023359, was opened at 2004-09-06 23:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023359&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Example does not match diagram. Initial Comment: The PEP describing the new type system changes in v2.2 introduces an inheritance diagram to illustrate a problem. After introducing the problem and solution, the "super" function is introduced. After that, a code example shows a use of super for the case in the diagram. The bug is that the inheritance shown in the diagram is not in the code, and the class definition should read "class D (B, C):" instead of "class D:". This is seen at: http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023359&group_id=5470 From noreply at sourceforge.net Tue Sep 7 01:44:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 01:44:23 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Raymond Hettinger (rhettinger) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Tue Sep 7 02:02:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 02:02:32 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 15:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 19:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 18:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Tue Sep 7 02:06:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 02:06:08 2004 Subject: [ python-Bugs-1023359 ] Example does not match diagram. Message-ID: Bugs item #1023359, was opened at 2004-09-06 18:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023359&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) >Assigned to: A.M. Kuchling (akuchling) Summary: Example does not match diagram. Initial Comment: The PEP describing the new type system changes in v2.2 introduces an inheritance diagram to illustrate a problem. After introducing the problem and solution, the "super" function is introduced. After that, a code example shows a use of super for the case in the diagram. The bug is that the inheritance shown in the diagram is not in the code, and the class definition should read "class D (B, C):" instead of "class D:". This is seen at: http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023359&group_id=5470 From noreply at sourceforge.net Tue Sep 7 04:52:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 04:52:26 2004 Subject: [ python-Bugs-1022813 ] test_xrange fails on osf1 v5.1b Message-ID: Bugs item #1022813, was opened at 2004-09-05 20:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022813&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Nobody/Anonymous (nobody) Summary: test_xrange fails on osf1 v5.1b Initial Comment: On a build of Python 2.4a3: uname -a: OSF1 xxx.tnzi.com V5.1 2650 alpha alpha > ./python ./Lib/test/test_xrange.py test_xrange (__main__.XrangeTest) ... ERROR ========================================== ============================ ERROR: test_xrange (__main__.XrangeTest) ------------------------------------------------------ ---------------- Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 56, in test_xrange self.assertEqual(len(xrange(-sys.maxint, sys.maxint, 2)), ValueError: xrange object size cannot be reported ------------------------------------------------------ ---------------- Ran 1 test in 0.001s FAILED (errors=1) Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 64, in ? test_main() File "./Lib/test/test_xrange.py", line 61, in test_main test.test_support.run_unittest(XrangeTest) File "/u03/home/doug/python/Python- 2.4a3/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/u03/home/doug/python/Python- 2.4a3/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "./Lib/test/test_xrange.py", line 56, in test_xrange self.assertEqual(len(xrange(-sys.maxint, sys.maxint, 2)), ValueError: xrange object size cannot be reported Everything else seems to work. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-09-06 22:52 Message: Logged In: YES user_id=33168 I haven't thought too much about this, but ISTM that the code is correct and the test needs to be updated. Unfortunately, I don't think there's anyway to test for LONG_MAX != INT_MAX. I think the best we could do is disable this test if sys.maxint > 0x7fffffff. Hmmm, you could probably use the struct module and find out the size of ints and longs. (struct.calcsize('i') and struct.calcsize('l')). But I'm tired, so all this could be non-sense. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 20:36 Message: Logged In: YES user_id=80475 I haven't looked into a solution yet but want to record what I've found so far. In checkin 2.44 on 9/11/2002, guido noted, """ Untested code for 64-bit platforms. range_length() is declared as int but returns r->len which is a long. This doesn't even cause a warning on 32-bit platforms, but can return bogus values on 64-bit platforms (and should cause a compiler warning). Fix this by inserting a range check when LONG_MAX != INT_MAX, and adding an explicit cast to (int) when the test passes. When r->len is out of range, PySequence_Size() and hence len() will report an error (but an iterator will still work). """ The code for the check is: static int range_length(rangeobject *r) { #if LONG_MAX != INT_MAX if (r->len > INT_MAX) { PyErr_SetString(PyExc_ValueError, "xrange object size cannot be reported"); return -1; } #endif return (int)(r->len); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022813&group_id=5470 From noreply at sourceforge.net Tue Sep 7 05:15:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 05:15:18 2004 Subject: [ python-Bugs-1019129 ] "rich comparison'' methods hide stack overflow Message-ID: Bugs item #1019129, was opened at 2004-08-30 08:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 >Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: boyanb (boyanb) Assigned to: Nobody/Anonymous (nobody) Summary: "rich comparison'' methods hide stack overflow Initial Comment: I've tried the code below for both 2.2.2 and 2.3.2 >>> class DontCare(str): ... def __eq__(self, other): ... # stack overflow expected! ... return self == other ... ... >>> print (DontCare("1") == "2") 1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-06 20:15 Message: Logged In: YES user_id=357491 This problem does not exist in 2.4 but seems to still be in 2.3 CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 From noreply at sourceforge.net Tue Sep 7 05:18:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 05:18:12 2004 Subject: [ python-Bugs-1019129 ] "rich comparison'' methods hide stack overflow Message-ID: Bugs item #1019129, was opened at 2004-08-30 10:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: boyanb (boyanb) Assigned to: Nobody/Anonymous (nobody) Summary: "rich comparison'' methods hide stack overflow Initial Comment: I've tried the code below for both 2.2.2 and 2.3.2 >>> class DontCare(str): ... def __eq__(self, other): ... # stack overflow expected! ... return self == other ... ... >>> print (DontCare("1") == "2") 1 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 22:18 Message: Logged In: YES user_id=80475 Armin fixed this for Py2.4. It is a behaviour change that may affect existing, working code, so it was not backported. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-06 22:15 Message: Logged In: YES user_id=357491 This problem does not exist in 2.4 but seems to still be in 2.3 CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 From noreply at sourceforge.net Tue Sep 7 05:29:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 05:29:34 2004 Subject: [ python-Bugs-1019129 ] "rich comparison'' methods hide stack overflow Message-ID: Bugs item #1019129, was opened at 2004-08-30 11:01 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: boyanb (boyanb) Assigned to: Nobody/Anonymous (nobody) Summary: "rich comparison'' methods hide stack overflow Initial Comment: I've tried the code below for both 2.2.2 and 2.3.2 >>> class DontCare(str): ... def __eq__(self, other): ... # stack overflow expected! ... return self == other ... ... >>> print (DontCare("1") == "2") 1 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-06 23:29 Message: Logged In: YES user_id=31435 Just nothing that this was still thought to be "a feature" in 2.3. NEWS for 2.4a1 contained: """ - Python no longer tries to be smart about recursive comparisons. When comparing containers with cyclic references to themselves it will now just hit the recursion limit. See SF patch 825639. """ More info can be found by looking at the patch, and the bug reports it addressed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 23:18 Message: Logged In: YES user_id=80475 Armin fixed this for Py2.4. It is a behaviour change that may affect existing, working code, so it was not backported. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-06 23:15 Message: Logged In: YES user_id=357491 This problem does not exist in 2.4 but seems to still be in 2.3 CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 From noreply at sourceforge.net Tue Sep 7 07:40:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 07:40:30 2004 Subject: [ python-Bugs-1023453 ] script which sets random.seed still returns random value Message-ID: Bugs item #1023453, was opened at 2004-09-07 05:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: script which sets random.seed still returns random value Initial Comment: Hi, The following text is in the README in the attached tarball. Note also that I'd be happy to try to narrow down the bug further, if indeed there is one. I just wanted to confirm first that there indeed was a bug. This is with python 2.3 and numarray 1.0 on Debian sarge. ii python-numarray 1.0-2 An array processing package modelled after Python-Numeric ii python 2.3.4-1 An interactive high-level object-oriented language (default version) (By the way, I'd really, really prefer to submit reports via email, like the Debian bug tracking system). It is also not very convenient to follow up to replies. Faheem ************************************************************* Run the included script (requires python 2.3) python bug.py Even though the seed is set before gendata is called, every time the script is run, a different matrix is printed. It seems to me that this should not happen. My interest in this case is ensuring reproducibility for debugging purposes. I am not an expert on random numbers, so I may be missing some subtle point. If so, I'm appreciate it if my error was explained to me. Thanks. Faheem Mitha. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 From noreply at sourceforge.net Tue Sep 7 08:31:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 08:32:00 2004 Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k Message-ID: Bugs item #989338, was opened at 2004-07-12 06:11 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' ====================================================================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' ====================================================================== ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 01:31 Message: Logged In: YES user_id=80475 Does this still fail for you in Py2.4a3 ? If not, please note the result and close the bug. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-18 01:44 Message: Logged In: YES user_id=358087 File system is NTFS. winver gives: Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 11:55 Message: Logged In: YES user_id=21627 Are you using a FAT partition? What precise version string do you get in winver.exe? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-13 01:10 Message: Logged In: YES user_id=358087 Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro. Any other data I can send? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-12 11:35 Message: Logged In: YES user_id=31435 Peculiar -- it works fine on WinXP Pro, which ought to work the same as Win2K here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 From noreply at sourceforge.net Tue Sep 7 08:56:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 08:56:18 2004 Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k Message-ID: Bugs item #989338, was opened at 2004-07-12 14:11 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' ====================================================================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' ====================================================================== ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-09-07 09:56 Message: Logged In: YES user_id=358087 Yes it does :-( I have a winXP on IBM T-40. The other language that is installed is Hebrew. The problem that when encoding TESTFN_UNICODE with the file system ecoding (mbcs) the resulted string is "@test-??" which is not a legal file name on windows ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 09:31 Message: Logged In: YES user_id=80475 Does this still fail for you in Py2.4a3 ? If not, please note the result and close the bug. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-18 09:44 Message: Logged In: YES user_id=358087 File system is NTFS. winver gives: Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 19:55 Message: Logged In: YES user_id=21627 Are you using a FAT partition? What precise version string do you get in winver.exe? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-13 09:10 Message: Logged In: YES user_id=358087 Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro. Any other data I can send? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-12 19:35 Message: Logged In: YES user_id=31435 Peculiar -- it works fine on WinXP Pro, which ought to work the same as Win2K here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 From noreply at sourceforge.net Tue Sep 7 09:13:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 09:13:48 2004 Subject: [ python-Bugs-1022951 ] make test fails on HP-UX11i Message-ID: Bugs item #1022951, was opened at 2004-09-06 03:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 Category: Build Group: Python 2.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: make test fails on HP-UX11i Initial Comment: Built Python-2.4a3 on HP-UX11i. When running make test, I get the following error: running build_scripts ./python -E -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"- "+sys.version[0:3]' >platform find ./Lib -name '*.py[co]' -print | xargs rm -f ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 (ignored) ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 02:13 Message: Logged In: YES user_id=80475 Thanks for report anyway. After that patch was posted, a couple of other changes were made. Since you have a system that treats _urandom differently from the rest of the development machines, it would be great if you could load the latest version, run the test, and report the results back here. The two files attached below. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-09-06 04:55 Message: Logged In: YES user_id=200117 Sorry, I should have read the bugs page first! Please disregard this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 From noreply at sourceforge.net Tue Sep 7 10:47:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 10:47:37 2004 Subject: [ python-Bugs-1023453 ] script which sets random.seed still returns random value Message-ID: Bugs item #1023453, was opened at 2004-09-07 00:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: script which sets random.seed still returns random value Initial Comment: Hi, The following text is in the README in the attached tarball. Note also that I'd be happy to try to narrow down the bug further, if indeed there is one. I just wanted to confirm first that there indeed was a bug. This is with python 2.3 and numarray 1.0 on Debian sarge. ii python-numarray 1.0-2 An array processing package modelled after Python-Numeric ii python 2.3.4-1 An interactive high-level object-oriented language (default version) (By the way, I'd really, really prefer to submit reports via email, like the Debian bug tracking system). It is also not very convenient to follow up to replies. Faheem ************************************************************* Run the included script (requires python 2.3) python bug.py Even though the seed is set before gendata is called, every time the script is run, a different matrix is printed. It seems to me that this should not happen. My interest in this case is ensuring reproducibility for debugging purposes. I am not an expert on random numbers, so I may be missing some subtle point. If so, I'm appreciate it if my error was explained to me. Thanks. Faheem Mitha. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 03:47 Message: Logged In: YES user_id=80475 There are two independent random number generators in your code. One is in the random module and you're accessing it with random.seed() and random.gammavariate(). The seed operation will correctly make gammavariate() create a reproducable sequence. The second is in numarray.random_array.multinomial. This generator is provided by numarray and needs its own seed operation. Seed it, and your program ought to work fine. See the numarray docs for details on how to seed random_array. For the future, please do not attach tar.gz files. They are a nuisance to review. More importantly, you should pair down the report to the simplest possible code that reproduces the error. Otherwise, a reviewer has to read all of your code to figure out what you're doing. Good luck and happy computing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 From noreply at sourceforge.net Tue Sep 7 12:49:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 12:49:23 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by squeen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 06:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 15:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 13:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 01:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 13:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 12:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 12:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 15:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 12:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 02:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 14:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 06:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 03:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 01:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 00:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 14:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 12:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 12:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 04:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 11:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 11:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 13:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 13:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 10:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 12:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 22:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 15:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 06:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 22:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 14:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 07:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 08:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 03:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 14:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 20:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 10:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 02:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 14:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 08:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Tue Sep 7 15:57:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 15:57:32 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 11:31 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- >Comment By: Paul D. Lusk (plusk) Date: 2004-09-07 09:57 Message: Logged In: YES user_id=1083789 Sorry that it has taken me so long to reply. We did not have a patch that understood unified diffs. I have applied the random patch from the bugs page and make test is not reporting any problems any more. Thanks for the prompt fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 07:48 Message: Logged In: YES user_id=80475 Paul, Can you please verify that the attached files run on your system. TIA, Raymond ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-03 15:10 Message: Logged In: YES user_id=80475 Fixed. See: LIb/random.py 1.66 Thanks for the prompt bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Tue Sep 7 16:37:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 16:37:55 2004 Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k Message-ID: Bugs item #989338, was opened at 2004-07-12 20:11 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' ====================================================================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' ====================================================================== ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-07 23:37 Message: Logged In: YES user_id=671362 I can reproduce this in Python 2.4a3 on Win 2K SP4(locale is set to Japanese). File system is NTFS. But on my box, test_single_files passes OK. Only test_equivalent_files and test_directories raise ERROR. Here is the result. test_unicode_file test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ok ============================================== ======================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 185, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_UNICODE+ext, True) File "C:\Python24\lib\test\test_unicode_file.py", line 114, in _do_directory os.chdir(chdir_name) OSError: [Errno 2] No such file or directory: u'@test-\xe0 \xf2.dir' ============================================== ======================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 176, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\Python24\lib\test\test_unicode_file.py", line 157, in _test_equivalent self._do_equivilent(filename1, filename2) File "C:\Python24\lib\test\test_unicode_file.py", line 67, in _do_equivilent os.stat(filename2)) OSError: [Errno 2] No such file or directory: u'@test-\xe0\xf2' ------------------------------------------------------------ ---------- Ran 3 tests in 0.070s FAILED (errors=2) test test_unicode_file failed -- errors occurred; run in verbose mode for details 1 test failed: test_unicode_file ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-09-07 15:56 Message: Logged In: YES user_id=358087 Yes it does :-( I have a winXP on IBM T-40. The other language that is installed is Hebrew. The problem that when encoding TESTFN_UNICODE with the file system ecoding (mbcs) the resulted string is "@test-??" which is not a legal file name on windows ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 15:31 Message: Logged In: YES user_id=80475 Does this still fail for you in Py2.4a3 ? If not, please note the result and close the bug. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-18 15:44 Message: Logged In: YES user_id=358087 File system is NTFS. winver gives: Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-16 01:55 Message: Logged In: YES user_id=21627 Are you using a FAT partition? What precise version string do you get in winver.exe? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-13 15:10 Message: Logged In: YES user_id=358087 Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro. Any other data I can send? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-13 01:35 Message: Logged In: YES user_id=31435 Peculiar -- it works fine on WinXP Pro, which ought to work the same as Win2K here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 From noreply at sourceforge.net Tue Sep 7 18:02:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 18:02:05 2004 Subject: [ python-Bugs-1009263 ] non-ascii readline input crashes python Message-ID: Bugs item #1009263, was opened at 2004-08-14 19:19 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: non-ascii readline input crashes python Initial Comment: Start Python 2.3.4 on Linux command line: $ python Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Enter the string "2?3" (2 times 3, the symbol between 2 and 3 is a multiplication sign, I think Unicode c397 or maybe 97c3 if I have it byte swapped) and hit return. Python reports a syntax error. Hit Ctrl-P to edit the line with readline. Use ctrl-D to delete the first character of the input line, and Python instantly crashes with a seg fault. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-07 17:02 Message: Logged In: YES user_id=6656 ping ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-16 13:29 Message: Logged In: YES user_id=6656 You should check the $LANG or $LC_ALL env vars. Or just run 'locale' in the shell. What version of readline are you using? Both instinct, and looking at the backtrace, suggest a readline bug to me. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-08-15 02:55 Message: Logged In: YES user_id=72053 Backtrace follows. I don't know how to tell my locale. My LOCALE shell variable is not set to anything--is there something else I need to check? Since the "2?3" displays properly in my terminal window, I think I'm likely using UTF-8. (gdb) r Starting program: /usr/local/bin/python [New Thread 1074951328 (LWP 6561)] Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 2?3 File "", line 1 2?3 ^ SyntaxError: invalid syntax >>> 2?3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1074951328 (LWP 6561)] 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 (gdb) bt #0 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 #1 0x401eb701 in _rl_compare_chars () from /usr/lib/libreadline.so.4 #2 0x401e0030 in rl_redisplay () from /usr/lib/libreadline.so.4 #3 0x401de816 in rl_redisplay () from /usr/lib/libreadline.so.4 #4 0x401d2588 in readline_internal_char () from /usr/lib/libreadline.so.4 #5 0x401d2695 in readline_internal_char () from /usr/lib/libreadline.so.4 #6 0x401d26ce in readline_internal_char () from /usr/lib/libreadline.so.4 #7 0x401d219f in readline () from /usr/lib/libreadline.so.4 #8 0x40019074 in call_readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at /home/phr/python/Python-2.3.4/Modules/readline.c:679 #9 0x080e6110 in PyOS_Readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at Parser/myreadline.c:183 #10 0x08056c47 in tok_nextc (tok=0x817f428) at Parser/tokenizer.c:683 #11 0x08055d8f in tok_get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1014 #12 0x080559de in PyTokenizer_Get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1414 #13 0x0805543a in parsetok (tok=0x817f428, g=0x8126b88, start=256, err_ret=0xbfffed10, flags=0) at Parser/parsetok.c:125 #14 0x080cb0e2 in PyRun_InteractiveOneFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:738 #15 0x080caf3b in PyRun_InteractiveLoopFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:690 #16 0x080cc2ee in PyRun_AnyFileExFlags (fp=0x4212fcc0, filename=0x80f004a "", closeit=0, flags=0xbfffedf8) at Python/pythonrun.c:653 #17 0x08054d32 in Py_Main (argc=0, argv=0xbfffee74) at Modules/main.c:415 #18 0x080548ab in main (argc=1, argv=0xbfffee74) at Modules/python.c:23 #19 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-14 22:10 Message: Logged In: YES user_id=55188 What locale do you use? I couldn't reproduce the problem on any of utf-8, iso8859-1, C, euc-kr locale. And, can you please attach a backtrace for the segfault point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 From noreply at sourceforge.net Tue Sep 7 18:07:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 18:07:53 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2004-09-07 16:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 10:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 19:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 17:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 05:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 17:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 16:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 16:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 20:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 20:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 19:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 17:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 06:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 18:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 10:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 05:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 17:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 16:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 16:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 08:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 16:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 16:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 18:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 18:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 15:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 17:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 03:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 19:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 10:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 02:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 18:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 11:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 12:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 07:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 18:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 00:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 14:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 06:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Tue Sep 7 18:18:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 18:18:30 2004 Subject: [ python-Bugs-1023798 ] test__locale fails Message-ID: Bugs item #1023798, was opened at 2004-09-07 17:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023798&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: test__locale fails Initial Comment: This is a bit strange. $ ./python ../Lib/test/regrtest.py test__locale test__locale test test__locale failed -- Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/mwh/src/python/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/mwh/src/python/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV 1 test failed: test__locale [13925 refs] Redhat 9, CVS as of a few minutes ago. The same problem, interactively: >>> import _locale, locale [27114 refs] >>> _locale.setlocale(_locale.LC_NUMERIC, 'lv_LV') 'lv_LV' [27155 refs] >>> locale.getlocale(locale.LC_NUMERIC) Traceback (most recent call last): File "", line 1, in ? File "/home/mwh/src/python/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/mwh/src/python/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV [27170 refs] setlocale() succeeds but subsequent getlocale()s fail, it seems. The test failure is fairly new, but the behaviour may be older, I guess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023798&group_id=5470 From noreply at sourceforge.net Tue Sep 7 18:20:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 18:21:09 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 10:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 11:20 Message: Logged In: YES user_id=80475 Glad to hear the bugs patch worked for you. Afterwards, I made further updates. Would appreciate it if you click on this bug report and get the two new files from SF and make sure they work on your machine. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-09-07 08:57 Message: Logged In: YES user_id=1083789 Sorry that it has taken me so long to reply. We did not have a patch that understood unified diffs. I have applied the random patch from the bugs page and make test is not reporting any problems any more. Thanks for the prompt fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 06:48 Message: Logged In: YES user_id=80475 Paul, Can you please verify that the attached files run on your system. TIA, Raymond ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-03 14:10 Message: Logged In: YES user_id=80475 Fixed. See: LIb/random.py 1.66 Thanks for the prompt bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Tue Sep 7 18:54:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 18:54:28 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 11:31 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- >Comment By: Paul D. Lusk (plusk) Date: 2004-09-07 12:54 Message: Logged In: YES user_id=1083789 I've download the attached files and run make test. All okay. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 12:20 Message: Logged In: YES user_id=80475 Glad to hear the bugs patch worked for you. Afterwards, I made further updates. Would appreciate it if you click on this bug report and get the two new files from SF and make sure they work on your machine. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-09-07 09:57 Message: Logged In: YES user_id=1083789 Sorry that it has taken me so long to reply. We did not have a patch that understood unified diffs. I have applied the random patch from the bugs page and make test is not reporting any problems any more. Thanks for the prompt fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 07:48 Message: Logged In: YES user_id=80475 Paul, Can you please verify that the attached files run on your system. TIA, Raymond ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-03 15:10 Message: Logged In: YES user_id=80475 Fixed. See: LIb/random.py 1.66 Thanks for the prompt bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Tue Sep 7 19:30:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 19:30:55 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 10:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Tue Sep 7 19:51:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 19:52:40 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2004-09-07 17:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 16:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 10:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 19:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 17:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 05:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 17:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 16:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 16:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 20:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 20:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 19:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 17:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 06:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 18:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 10:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 05:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 17:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 16:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 16:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 08:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 16:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 16:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 18:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 18:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 15:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 17:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 03:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 19:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 10:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 02:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 18:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 11:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 12:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 07:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 18:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 00:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 14:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 06:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Tue Sep 7 19:57:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 19:57:50 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 13:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-07 13:57 Message: Logged In: YES user_id=31435 What are LONG_BIT and SIZEOF_LONG on these platforms? It doesn't matter whether gcc is being used, if LONG_BIT is defined incorrectly for the platform, then it's defined incorrectly period. Read the comment you quoted to see why it doesn't matter whether Python "compiles fine" if you disable this. It's guarding against runtime errors in Python's intobject.c, which needs a correct value for LONG_BIT. Presumably LONG_BIT should be 64 on these boxes, and SIZEOF_LONG should be 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Wed Sep 8 00:19:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 00:19:37 2004 Subject: [ python-Bugs-1023453 ] script which sets random.seed still returns random value Message-ID: Bugs item #1023453, was opened at 2004-09-07 05:40 Message generated for change (Comment added) made by fmitha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: script which sets random.seed still returns random value Initial Comment: Hi, The following text is in the README in the attached tarball. Note also that I'd be happy to try to narrow down the bug further, if indeed there is one. I just wanted to confirm first that there indeed was a bug. This is with python 2.3 and numarray 1.0 on Debian sarge. ii python-numarray 1.0-2 An array processing package modelled after Python-Numeric ii python 2.3.4-1 An interactive high-level object-oriented language (default version) (By the way, I'd really, really prefer to submit reports via email, like the Debian bug tracking system). It is also not very convenient to follow up to replies. Faheem ************************************************************* Run the included script (requires python 2.3) python bug.py Even though the seed is set before gendata is called, every time the script is run, a different matrix is printed. It seems to me that this should not happen. My interest in this case is ensuring reproducibility for debugging purposes. I am not an expert on random numbers, so I may be missing some subtle point. If so, I'm appreciate it if my error was explained to me. Thanks. Faheem Mitha. ---------------------------------------------------------------------- >Comment By: Faheem Mitha (fmitha) Date: 2004-09-07 22:19 Message: Logged In: YES user_id=1063525 > Date: 2004-09-07 08:47 > Sender: rhettinger > Logged In: YES > user_id=80475 > There are two independent random number generators in your code. > One is in the random module and you're accessing it with > random.seed() and random.gammavariate(). The seed operation > will correctly make gammavariate() create a reproducable > sequence. > The second is in numarray.random_array.multinomial. This > generator is provided by numarray and needs its own seed > operation. Seed it, and your program ought to work fine. > See the numarray docs for details on how to seed random_array. I see. Thanks for explaining this. I did try to track down this bug, but I never realised that numarray was using a different random number generator. I think it would be a good idea to standardise on a single interface. > For the future, please do not attach tar.gz files. They are > a nuisance to review. What do you want instead? 1) Code attached as text file? 2) Code included in the message? I don't think this would work as the web form would probably mess up the indentation. 3) A link to a web page? But this would mean the info would not be contained in the bug report for posterity. :-) Or something else? > More importantly, you should pair down the report to the simplest > possible code that reproduces the error. Otherwise, a reviewer has to > read all of your code to figure out what you're doing. Yes, I probably should have taken the time to narrow down the problem, and in the process might have solved it. However, at the time I submitted, I had already run into this problem several times without figuring it out, and had spent some time narrowing down the problem to a region of code. As I said in the report, I just wanted to confirm that this actually was a bug. As I also said, I was quite willing to spend additional time narrowing it down if it was indeed a bug, but in in the first place it seemed difficult since I had no idea why it should occur. Faheem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 08:47 Message: Logged In: YES user_id=80475 There are two independent random number generators in your code. One is in the random module and you're accessing it with random.seed() and random.gammavariate(). The seed operation will correctly make gammavariate() create a reproducable sequence. The second is in numarray.random_array.multinomial. This generator is provided by numarray and needs its own seed operation. Seed it, and your program ought to work fine. See the numarray docs for details on how to seed random_array. For the future, please do not attach tar.gz files. They are a nuisance to review. More importantly, you should pair down the report to the simplest possible code that reproduces the error. Otherwise, a reviewer has to read all of your code to figure out what you're doing. Good luck and happy computing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 From noreply at sourceforge.net Wed Sep 8 00:28:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 00:28:49 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 10:18 Message generated for change (Comment added) made by ssmmhh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Simon Harrison (ssmmhh) Date: 2004-09-07 22:28 Message: Logged In: YES user_id=775521 I'm still looking at this, but running into difficulties. - Having looked again at readdir_r manual page I can't work out the buffer sizing. If anyone can point me at some example code I'd appreciate it. - I can't compile 2.4a3 on Solaris - got an error during configure about term.h present but can't be compiled, and therefore can't check my latest patch works. System: Solaris 8 2/02, gcc 3.3.3. I'm not in a position to change any of these versions, unfortunately. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 20:07 Message: Logged In: YES user_id=775521 Point taken about readdir_r and getaddrinfo. I'll submit something more robust (and tested) probably next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 16:23 Message: Logged In: YES user_id=21627 The patch looks good. It doesn't need to be complete, but it should be correct for the APIs which it does change. A few comments: - there is probably little point in changing getaddrinfo.c. This is an emulation that is only used on systems which don't have a "proper" getaddrinfo, and most likely, all systems offering gethostbyname_r also offer getaddrinfo. - the usage of readdir_r is incorrect - you need to provide for sufficient space. - I don't think it is good to allocate 8k on the stack. Instead, you should indeed start with a small buffer, then grow it as needed, using malloc. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 12:15 Message: Logged In: YES user_id=775521 Don't apply the patch - it's not tested, but just serves as an example, and it's certainly not complete. For some _r functions it's quite obvious how they should be used. For ones with variable-length buffers accompanying the struct to be filled in it's not clear how they should be sized. It's also not clear whether the ERANGE return should be used to 'automatically' realloc a larger buffer, or whether the ERANGE error should simply be passed back to Python as a general failure. For some buffers (asctime_r) the maximum size can be guessed based on common sense, for others, defines exist in system headers which may not be portable, requiring possible further configure checks. I think the way I would fix this is to introduce a wrapper for each reentrant function that returns a malloc'ed buffer that must be freed by the caller when done with the structure. The wrapper would continually allocate larger buffers until the size was correct. Alteratively, one might argue I'm being overly paranoid, and that for each function we should be able to guess a sensible buffer length, then just fail if the api call returns too much data. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 20:55 Message: Logged In: YES user_id=21627 In private email, Simon pointed out that there is a problem if Python is embedded and the embedded application simultaneously also invokes non-reentrant functions. I'm still uncertain whether that problem would be a bug in Python, and if it is, whether it is worthwhile getting fixed. OTOH, contributions would be certainly accepted. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 16:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Wed Sep 8 04:03:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 04:03:53 2004 Subject: [ python-Bugs-1023798 ] test__locale fails Message-ID: Bugs item #1023798, was opened at 2004-09-07 09:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023798&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Brett Cannon (bcannon) Summary: test__locale fails Initial Comment: This is a bit strange. $ ./python ../Lib/test/regrtest.py test__locale test__locale test test__locale failed -- Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/mwh/src/python/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/mwh/src/python/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV 1 test failed: test__locale [13925 refs] Redhat 9, CVS as of a few minutes ago. The same problem, interactively: >>> import _locale, locale [27114 refs] >>> _locale.setlocale(_locale.LC_NUMERIC, 'lv_LV') 'lv_LV' [27155 refs] >>> locale.getlocale(locale.LC_NUMERIC) Traceback (most recent call last): File "", line 1, in ? File "/home/mwh/src/python/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/mwh/src/python/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV [27170 refs] setlocale() succeeds but subsequent getlocale()s fail, it seems. The test failure is fairly new, but the behaviour may be older, I guess. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-07 19:03 Message: Logged In: YES user_id=357491 Fixed in rev 1.8 . Problem was from when I moved test__locale over to unittest. Now it uses setlocale and guards against the lookup failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023798&group_id=5470 From noreply at sourceforge.net Wed Sep 8 06:45:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 06:45:33 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 12:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 06:45 Message: Logged In: YES user_id=21627 One approach of using readdir_r is presented at http://www.belgeler.org/glibc/glibc-Reading-Closing-Directory.html As for not being able to compile 2.4a3, please add a new bug report, and show the relevant fragment of config.log in that report. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-08 00:28 Message: Logged In: YES user_id=775521 I'm still looking at this, but running into difficulties. - Having looked again at readdir_r manual page I can't work out the buffer sizing. If anyone can point me at some example code I'd appreciate it. - I can't compile 2.4a3 on Solaris - got an error during configure about term.h present but can't be compiled, and therefore can't check my latest patch works. System: Solaris 8 2/02, gcc 3.3.3. I'm not in a position to change any of these versions, unfortunately. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 22:07 Message: Logged In: YES user_id=775521 Point taken about readdir_r and getaddrinfo. I'll submit something more robust (and tested) probably next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 18:23 Message: Logged In: YES user_id=21627 The patch looks good. It doesn't need to be complete, but it should be correct for the APIs which it does change. A few comments: - there is probably little point in changing getaddrinfo.c. This is an emulation that is only used on systems which don't have a "proper" getaddrinfo, and most likely, all systems offering gethostbyname_r also offer getaddrinfo. - the usage of readdir_r is incorrect - you need to provide for sufficient space. - I don't think it is good to allocate 8k on the stack. Instead, you should indeed start with a small buffer, then grow it as needed, using malloc. ---------------------------------------------------------------------- Comment By: Simon Harrison (ssmmhh) Date: 2004-09-05 14:15 Message: Logged In: YES user_id=775521 Don't apply the patch - it's not tested, but just serves as an example, and it's certainly not complete. For some _r functions it's quite obvious how they should be used. For ones with variable-length buffers accompanying the struct to be filled in it's not clear how they should be sized. It's also not clear whether the ERANGE return should be used to 'automatically' realloc a larger buffer, or whether the ERANGE error should simply be passed back to Python as a general failure. For some buffers (asctime_r) the maximum size can be guessed based on common sense, for others, defines exist in system headers which may not be portable, requiring possible further configure checks. I think the way I would fix this is to introduce a wrapper for each reentrant function that returns a malloc'ed buffer that must be freed by the caller when done with the structure. The wrapper would continually allocate larger buffers until the size was correct. Alteratively, one might argue I'm being overly paranoid, and that for each function we should be able to guess a sensible buffer length, then just fail if the api call returns too much data. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 22:55 Message: Logged In: YES user_id=21627 In private email, Simon pointed out that there is a problem if Python is embedded and the embedded application simultaneously also invokes non-reentrant functions. I'm still uncertain whether that problem would be a bug in Python, and if it is, whether it is worthwhile getting fixed. OTOH, contributions would be certainly accepted. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 18:47 Message: Logged In: YES user_id=21627 I fail to see the bug. I believe Python uses the reentrant functions at precisely the places where it is necessary, and is right in using the non-reentrant functions in all other places. To my knowledge, the way that Python uses the non-reentrant functions cannot possibly cause problems even on multiprocessor machines. So I'm closing this report as invalid. If you can find an actual problem using your script, please submit a new bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Wed Sep 8 09:12:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 09:12:42 2004 Subject: [ python-Bugs-1022951 ] make test fails on HP-UX11i Message-ID: Bugs item #1022951, was opened at 2004-09-06 09:57 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 Category: Build Group: Python 2.4 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: make test fails on HP-UX11i Initial Comment: Built Python-2.4a3 on HP-UX11i. When running make test, I get the following error: running build_scripts ./python -E -c 'import sys ; from distutils.util import get_platform ; print get_platform()+"- "+sys.version[0:3]' >platform find ./Lib -name '*.py[co]' -print | xargs rm -f ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 (ignored) ./python -E -tt ./Lib/test/regrtest.py -l Traceback (most recent call last): File "./Lib/test/regrtest.py", line 98, in ? import random File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 834, in ? _inst = Random() File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 100, in __init__ self.seed(x) File "/home/richardt/python-24/Python- 2.4a3/Lib/random.py", line 117, in seed a = long(_hexlify(_urandom(16)), 16) File "/home/richardt/python-24/Python- 2.4a3/Lib/os.py", line 675, in urandom raise NotImplementedError("/dev/urandom (or equivalent) not found") NotImplementedError: /dev/urandom (or equivalent) not found *** Error exit code 1 ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2004-09-08 08:12 Message: Logged In: YES user_id=200117 I copied the two files to my Python-2.4a3 installation and ran the test - all 37 tests ran OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 08:13 Message: Logged In: YES user_id=80475 Thanks for report anyway. After that patch was posted, a couple of other changes were made. Since you have a system that treats _urandom differently from the rest of the development machines, it would be great if you could load the latest version, run the test, and report the results back here. The two files attached below. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-09-06 10:55 Message: Logged In: YES user_id=200117 Sorry, I should have read the bugs page first! Please disregard this report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022951&group_id=5470 From noreply at sourceforge.net Wed Sep 8 11:24:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 11:24:36 2004 Subject: [ python-Bugs-1022152 ] Bad examples of gettext.translation Message-ID: Bugs item #1022152, was opened at 2004-09-04 09:22 Message generated for change (Comment added) made by adurdin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022152&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Bad examples of gettext.translation Initial Comment: The usage examples on "6.27.3.3 Changing languages on the fly" (http://www.python.org/dev/doc/devel/lib/node293.html) are incorrect, because of the syntax of gettext.translation. The examples just don't match "6.27.2 Class-based API" (http://www.python.org/dev/doc/devel/lib/node285.html), and they gave me an error when tried them:the "domain" is not optional. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-08 19:24 Message: Logged In: YES user_id=625864 Same issue here when I tried it. I've created patch #1024238 to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022152&group_id=5470 From noreply at sourceforge.net Wed Sep 8 11:52:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 11:52:33 2004 Subject: [ python-Bugs-1002453 ] Wrong documentation of __radd__ etc. Message-ID: Bugs item #1002453, was opened at 2004-08-03 17:25 Message generated for change (Comment added) made by adurdin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong documentation of __radd__ etc. Initial Comment: Info node 'Emulating numeric types' says: __radd__(self, other) __rsub__(self, other) ... These functions are only called if the left operand does not support the corresponding operation. Not so. Info node 'Coercion rules' lists one exception: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class, the right operand's `__rop__()' method is tried _before_ the left operand's `__op__()' method. ...and one time where above the text is misleading: When either operand type defines a coercion, this coercion is called before that type's `__op__()' or `__rop__()' method is called, but no sooner. If the coercion returns an object of a different type for the operand whose coercion is invoked, part of the process is redone using the new object. Thus, Python can call __rop__(self, other) even if self.__op__ exists: If one does `x - y' where y.__coerce__(x) coerces x to y's class, y.__rsub__(x) is called instead of (coerced x).__sub__(y). I think this should be documented in the 'Emulating numeric types' node. Unless Python is changed to redo the choice between __op__, __rop__ and __iop__ after coercion. I think it would also be good to explain in that Info node what __op__ and __rop__ can do if they do not support the operation with the supplied arguments, but the other argument might support it. It seems obvious that self.__op__(other) can simply attempt to call other.__rop__(self) and let that fail if it is not supported. However, the above rules seem to mean that self.__rop__(other) might want to call other.__op__(self) too, which could lead to infinite recursion. Are there some special times where it can do that, and other times where it should not? ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-08 19:52 Message: Logged In: YES user_id=625864 > I think it would also be good to explain in that Info > node what __op__ and __rop__ can do if they do not > support the operation with the supplied arguments In that case I believe they should just return NotImplemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470 From noreply at sourceforge.net Wed Sep 8 14:37:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 14:40:35 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by peterkleiweg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 14:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 13:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 12:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Wed Sep 8 16:54:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 16:54:20 2004 Subject: [ python-Bugs-1024427 ] WinCVS doesn't recognize 2.4a3 Message-ID: Bugs item #1024427, was opened at 2004-09-08 07:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David W. Thomas (davidwt) Assigned to: Nobody/Anonymous (nobody) Summary: WinCVS doesn't recognize 2.4a3 Initial Comment: WinCVS does not recognize the alpha release of 2.4 after using the .msi installation of python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 From noreply at sourceforge.net Wed Sep 8 17:14:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 17:14:42 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-04 03:46 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2004-09-09 00:14 Message: Logged In: YES user_id=671362 Hi, Martin. Your fix doesn't look enough for me. I tried a new installer but noticed that all command-line argumetns(install, --help, etc) are ignored. I think adding %* after "%1" is necessary. Then the file association to *.py files looks like: "C:\Python24\python.exe" "%1" %* or "C:\Python24\python.exe" -console "%1" %* # CVS HEAD Thanks in advance. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 18:01 Message: Logged In: YES user_id=21627 Thanks for your report. I have re-rolled the package, and Anthony has made it available from http://www.python.org/ftp/python/2.4/python-2.4a3.2.msi I will commit the changes to msi.py shortly. I have left the Itanium installer untouched - Itanium users will either fix the extensions themselves, or wait for 2.4b1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-04 13:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 10:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 08:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Wed Sep 8 20:09:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 20:09:39 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-03 20:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 >Status: Open Resolution: Fixed >Priority: 7 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 20:09 Message: Logged In: YES user_id=21627 I see. Until yesterday, I didn't even know you can use the open verb in contexts other than double-clicking. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-08 17:14 Message: Logged In: YES user_id=671362 Hi, Martin. Your fix doesn't look enough for me. I tried a new installer but noticed that all command-line argumetns(install, --help, etc) are ignored. I think adding %* after "%1" is necessary. Then the file association to *.py files looks like: "C:\Python24\python.exe" "%1" %* or "C:\Python24\python.exe" -console "%1" %* # CVS HEAD Thanks in advance. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 11:01 Message: Logged In: YES user_id=21627 Thanks for your report. I have re-rolled the package, and Anthony has made it available from http://www.python.org/ftp/python/2.4/python-2.4a3.2.msi I will commit the changes to msi.py shortly. I have left the Itanium installer untouched - Itanium users will either fix the extensions themselves, or wait for 2.4b1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-04 06:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 03:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 01:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Wed Sep 8 20:09:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 20:10:03 2004 Subject: [ python-Bugs-1024427 ] WinCVS doesn't recognize 2.4a3 Message-ID: Bugs item #1024427, was opened at 2004-09-08 16:54 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: David W. Thomas (davidwt) >Assigned to: Martin v. L?wis (loewis) Summary: WinCVS doesn't recognize 2.4a3 Initial Comment: WinCVS does not recognize the alpha release of 2.4 after using the .msi installation of python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 From noreply at sourceforge.net Wed Sep 8 20:24:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 20:24:44 2004 Subject: [ python-Bugs-1022880 ] random.shuffle should restrict the type of its argument Message-ID: Bugs item #1022880, was opened at 2004-09-05 23:45 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: random.shuffle should restrict the type of its argument Initial Comment: Consider the following ******************************************** In [1]: foo = numstr.array(['a', 'c'], shape=(2,1)) In [2]: import random In [3]: import numarray.strings as numstr In [4]: foo Out[4]: CharArray([['a'], ['c']]) In [5]: random.shuffle(foo) In [6]: foo Out[64]: CharArray([['a'], ['a']]) ********************************************** The documentation says that shuffle takes a list as argument. In this case it accepts a Numarray character array without complaint and returns gibberish. I think there should be some restrictions on what arguments are accepted. Thanks. Faheem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 02:10 Message: Logged In: YES user_id=80475 I don't see a way to detect your issue without breaking shufflle's current capability of working with a variety of mutable sequences. Changing that would likely break code that is currently working fine. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 01:18 Message: Logged In: YES user_id=1063525 >> Comment By: Raymond Hettinger (rhettinger) > Date: 2004-09-06 00:16 > > Message: > Logged In: YES > user_id=80475 > > While in your case it worked out badly, python's duck typing > is a core design principle. It is a feature that mutable > sequences (listlike objects) can be passed as arguments and > shuffle does the riight thing. Yes, but in this case, it does not do the right thing. > It is unfornate that the 2D arrays look like lists (having > __len__, __getitem__, and __setitem__) but behave in ways > that are unlike other sequences. For your use case, first > flatten the array and then shuffle it: > x = foo.tolist() > shuffle(x) Yes, that is what I did. > So, this is not a bug but I'm leaving it open for a bit in > case others want to comment. Faheem. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-06 01:14 Message: Logged In: YES user_id=1063525 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 00:16 Message: Logged In: YES user_id=80475 While in your case it worked out badly, python's duck typing is a core design principle. It is a feature that mutable sequences (listlike objects) can be passed as arguments and shuffle does the riight thing. It is unfornate that the 2D arrays look like lists (having __len__, __getitem__, and __setitem__) but behave in ways that are unlike other sequences. For your use case, first flatten the array and then shuffle it: x = foo.tolist() shuffle(x) So, this is not a bug but I'm leaving it open for a bit in case others want to comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022880&group_id=5470 From noreply at sourceforge.net Wed Sep 8 20:30:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 20:30:55 2004 Subject: [ python-Bugs-1023453 ] script which sets random.seed still returns random value Message-ID: Bugs item #1023453, was opened at 2004-09-07 00:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Faheem Mitha (fmitha) Assigned to: Nobody/Anonymous (nobody) Summary: script which sets random.seed still returns random value Initial Comment: Hi, The following text is in the README in the attached tarball. Note also that I'd be happy to try to narrow down the bug further, if indeed there is one. I just wanted to confirm first that there indeed was a bug. This is with python 2.3 and numarray 1.0 on Debian sarge. ii python-numarray 1.0-2 An array processing package modelled after Python-Numeric ii python 2.3.4-1 An interactive high-level object-oriented language (default version) (By the way, I'd really, really prefer to submit reports via email, like the Debian bug tracking system). It is also not very convenient to follow up to replies. Faheem ************************************************************* Run the included script (requires python 2.3) python bug.py Even though the seed is set before gendata is called, every time the script is run, a different matrix is printed. It seems to me that this should not happen. My interest in this case is ensuring reproducibility for debugging purposes. I am not an expert on random numbers, so I may be missing some subtle point. If so, I'm appreciate it if my error was explained to me. Thanks. Faheem Mitha. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 13:30 Message: Logged In: YES user_id=80475 Since the two generators are in different products (different people make and distribute Numeric), unifying them would be a bit of a trick. Consider posting a change request on their site. ---------------------------------------------------------------------- Comment By: Faheem Mitha (fmitha) Date: 2004-09-07 17:19 Message: Logged In: YES user_id=1063525 > Date: 2004-09-07 08:47 > Sender: rhettinger > Logged In: YES > user_id=80475 > There are two independent random number generators in your code. > One is in the random module and you're accessing it with > random.seed() and random.gammavariate(). The seed operation > will correctly make gammavariate() create a reproducable > sequence. > The second is in numarray.random_array.multinomial. This > generator is provided by numarray and needs its own seed > operation. Seed it, and your program ought to work fine. > See the numarray docs for details on how to seed random_array. I see. Thanks for explaining this. I did try to track down this bug, but I never realised that numarray was using a different random number generator. I think it would be a good idea to standardise on a single interface. > For the future, please do not attach tar.gz files. They are > a nuisance to review. What do you want instead? 1) Code attached as text file? 2) Code included in the message? I don't think this would work as the web form would probably mess up the indentation. 3) A link to a web page? But this would mean the info would not be contained in the bug report for posterity. :-) Or something else? > More importantly, you should pair down the report to the simplest > possible code that reproduces the error. Otherwise, a reviewer has to > read all of your code to figure out what you're doing. Yes, I probably should have taken the time to narrow down the problem, and in the process might have solved it. However, at the time I submitted, I had already run into this problem several times without figuring it out, and had spent some time narrowing down the problem to a region of code. As I said in the report, I just wanted to confirm that this actually was a bug. As I also said, I was quite willing to spend additional time narrowing it down if it was indeed a bug, but in in the first place it seemed difficult since I had no idea why it should occur. Faheem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 03:47 Message: Logged In: YES user_id=80475 There are two independent random number generators in your code. One is in the random module and you're accessing it with random.seed() and random.gammavariate(). The seed operation will correctly make gammavariate() create a reproducable sequence. The second is in numarray.random_array.multinomial. This generator is provided by numarray and needs its own seed operation. Seed it, and your program ought to work fine. See the numarray docs for details on how to seed random_array. For the future, please do not attach tar.gz files. They are a nuisance to review. More importantly, you should pair down the report to the simplest possible code that reproduces the error. Otherwise, a reviewer has to read all of your code to figure out what you're doing. Good luck and happy computing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023453&group_id=5470 From noreply at sourceforge.net Wed Sep 8 20:45:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 20:46:07 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 09:25 Message generated for change (Comment added) made by kowaltowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-08 15:45 Message: Logged In: YES user_id=185428 Tested with the alpha version Python-2.4a3. It works properly! ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-26 08:26 Message: Logged In: YES user_id=185428 I did not find the file 'thread_pthread.h' under my installation :-(. My program in C is: ---------------------------------------------------------- #include #include #include void *ExecuteCommand( void *ptr ) { char *command = ptr; int result = system(command); printf("Tested the command: %s; result = %d\n",command,result); return NULL; } int main() { pthread_t thread; pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_04/bin/java -cp . DoNothing"); pthread_join(thread,NULL); pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_05/bin/java -cp . DoNothing"); pthread_join(thread,NULL); return 0; } ---------------------------------------------------------- It correctly prints 0 for both threads. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-26 01:37 Message: Logged In: YES user_id=33168 There's another possibility, but I'm not sure if it would affect your build or not. It's possible to set a smaller stack size when creating a thread. This would mean that THREAD_STACK_SIZE is set. If you look in ./Python/thread_pthread.h you will see the references. THREAD_STACK_SIZE is not set on my box. In your C test, did you pass NULL for the attributes or did you do pthread_attr_init(). It's possible that is the difference between your C test and python. You might try mucking in ./Python/thread_pthread.h to see if you can determine what is happening. ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 21:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 19:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Wed Sep 8 20:56:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 20:56:09 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 07:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 13:56 Message: Logged In: YES user_id=80475 So, can this be closed as "out-of-date"? ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-08 13:45 Message: Logged In: YES user_id=185428 Tested with the alpha version Python-2.4a3. It works properly! ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-26 06:26 Message: Logged In: YES user_id=185428 I did not find the file 'thread_pthread.h' under my installation :-(. My program in C is: ---------------------------------------------------------- #include #include #include void *ExecuteCommand( void *ptr ) { char *command = ptr; int result = system(command); printf("Tested the command: %s; result = %d\n",command,result); return NULL; } int main() { pthread_t thread; pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_04/bin/java -cp . DoNothing"); pthread_join(thread,NULL); pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_05/bin/java -cp . DoNothing"); pthread_join(thread,NULL); return 0; } ---------------------------------------------------------- It correctly prints 0 for both threads. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 23:37 Message: Logged In: YES user_id=33168 There's another possibility, but I'm not sure if it would affect your build or not. It's possible to set a smaller stack size when creating a thread. This would mean that THREAD_STACK_SIZE is set. If you look in ./Python/thread_pthread.h you will see the references. THREAD_STACK_SIZE is not set on my box. In your C test, did you pass NULL for the attributes or did you do pthread_attr_init(). It's possible that is the difference between your C test and python. You might try mucking in ./Python/thread_pthread.h to see if you can determine what is happening. ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 19:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 17:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Wed Sep 8 21:15:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 21:15:48 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 22:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 21:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 02:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-07 01:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Wed Sep 8 21:30:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 21:30:41 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 15:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 14:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 19:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 18:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Wed Sep 8 23:00:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 23:00:33 2004 Subject: [ python-Bugs-1024669 ] struct.calcsize() behaves strangely with short type Message-ID: Bugs item #1024669, was opened at 2004-09-09 00:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024669&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Serafeim Zanikolas (serzan) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize() behaves strangely with short type Initial Comment: Example: from struct import calcsize calcsize('h') reports 2 calcsize('i') reports 4, but calcsize('hi') reports 8! (same with calcsize('hhi')) Am I missing something or isn't it the case that calcsize('h') should report 4? python version: Python 2.3.3 (#1, May 25 2004, 16:51:30) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 uname -a output: Linux XXXX 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686 i686 i386 GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024669&group_id=5470 From noreply at sourceforge.net Wed Sep 8 23:39:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 23:44:17 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by peterkleiweg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 23:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 14:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 13:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 12:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Wed Sep 8 23:45:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 23:45:36 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 22:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 23:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 21:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 21:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 02:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-07 01:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 9 00:03:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 00:03:50 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 9 00:38:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 00:38:19 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 9 00:53:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 00:53:39 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 22:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-09 00:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-09 00:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-09 00:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 23:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 21:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 21:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 02:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-07 01:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 9 01:52:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 01:52:47 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 09:25 Message generated for change (Comment added) made by kowaltowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-08 20:52 Message: Logged In: YES user_id=185428 I guess so even though 2.4 is still alpha. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 15:56 Message: Logged In: YES user_id=80475 So, can this be closed as "out-of-date"? ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-08 15:45 Message: Logged In: YES user_id=185428 Tested with the alpha version Python-2.4a3. It works properly! ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-26 08:26 Message: Logged In: YES user_id=185428 I did not find the file 'thread_pthread.h' under my installation :-(. My program in C is: ---------------------------------------------------------- #include #include #include void *ExecuteCommand( void *ptr ) { char *command = ptr; int result = system(command); printf("Tested the command: %s; result = %d\n",command,result); return NULL; } int main() { pthread_t thread; pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_04/bin/java -cp . DoNothing"); pthread_join(thread,NULL); pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_05/bin/java -cp . DoNothing"); pthread_join(thread,NULL); return 0; } ---------------------------------------------------------- It correctly prints 0 for both threads. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-26 01:37 Message: Logged In: YES user_id=33168 There's another possibility, but I'm not sure if it would affect your build or not. It's possible to set a smaller stack size when creating a thread. This would mean that THREAD_STACK_SIZE is set. If you look in ./Python/thread_pthread.h you will see the references. THREAD_STACK_SIZE is not set on my box. In your C test, did you pass NULL for the attributes or did you do pthread_attr_init(). It's possible that is the difference between your C test and python. You might try mucking in ./Python/thread_pthread.h to see if you can determine what is happening. ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 21:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 19:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Thu Sep 9 02:21:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 02:22:04 2004 Subject: [ python-Bugs-1021890 ] Import random fails Message-ID: Bugs item #1021890, was opened at 2004-09-03 10:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Raymond Hettinger (rhettinger) Summary: Import random fails Initial Comment: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license import random fails. There is no /dev/urandom on this machine, so os.urandom raises: NotImplementedError: /dev/urandom (or equivalent) not found The code in random.py seems to expect that os.urandom exists that urandom will work. Possible patch: Change random.py so that that urandom usage is setup like this: try: from os import urandom as _urandom from binascii import hexlify as _hexlify except ImportError: _urandom = None else: try: _urandom(1) except NotImplementedError: _urandom = None After this, import random works. test_random still fails for the HardwareRandom tests, of course. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 19:21 Message: Logged In: YES user_id=80475 Thx. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-09-07 11:54 Message: Logged In: YES user_id=1083789 I've download the attached files and run make test. All okay. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 11:20 Message: Logged In: YES user_id=80475 Glad to hear the bugs patch worked for you. Afterwards, I made further updates. Would appreciate it if you click on this bug report and get the two new files from SF and make sure they work on your machine. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-09-07 08:57 Message: Logged In: YES user_id=1083789 Sorry that it has taken me so long to reply. We did not have a patch that understood unified diffs. I have applied the random patch from the bugs page and make test is not reporting any problems any more. Thanks for the prompt fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 06:48 Message: Logged In: YES user_id=80475 Paul, Can you please verify that the attached files run on your system. TIA, Raymond ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-03 14:10 Message: Logged In: YES user_id=80475 Fixed. See: LIb/random.py 1.66 Thanks for the prompt bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021890&group_id=5470 From noreply at sourceforge.net Thu Sep 9 07:18:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 07:23:22 2004 Subject: [ python-Bugs-736659 ] markupbase parse_declaration cannot recognize comments Message-ID: Bugs item #736659, was opened at 2003-05-12 16:34 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736659&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: markupbase parse_declaration cannot recognize comments Initial Comment: In markupbase class parser method parse_declaration It verfies that the first two characters are "<!" Then it returns -1 if the next character is "-". After that, it checks to see if the next two characters are "--", but if they were, it would already have returned. Solution: Check for comments before checking for a short buffer. if rawdata[j:j+1] == '--': #comment # Locate --.*-- as the body of the comment return self.parse_comment(i) if rawdata[j:j+1] in ("-", ""): # Start of comment followed by buffer # boundary, or just a buffer boundary. return -1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-09-09 01:18 Message: Logged In: YES user_id=3066 As noted in the related patch (#901369), this probably shouldn't be considered a bug. Keeping this open pending outcome of email discussion with OP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736659&group_id=5470 From noreply at sourceforge.net Thu Sep 9 10:04:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 10:04:47 2004 Subject: [ python-Bugs-857676 ] RE engine internal error with LARGE RE: scalability bug Message-ID: Bugs item #857676, was opened at 2003-12-10 17:21 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Francisco Dellatorre Borges (fdborges) Assigned to: Fredrik Lundh (effbot) Summary: RE engine internal error with LARGE RE: scalability bug Initial Comment: I lot's of lines with the format: (d+@w[^|]+|)+ I'll call the last bit after the @ of /features/. I need to delete some of these, so I have this code that would produce a list matching what I would /not/ use, pass it over re.escape and them build a re using a concatenation of the list and delete this from the text before actually doing any parsing. Problem is: I have about 220.000 different features and I need to delete some 200.000 different ones from my files before doing something. So I tried to use a list of the 20.000 I want and then delete anything that matches the <not> of it: #--------------- # ftrlist is the stuff I *want* to keep: ftrlist = [re.escape(i) for i in ftrlist ] re.compile(r'(?!(%s))' %( '|'.join(ftrlist)) ) #-------------- but when I apply it I get something like: RuntimeError: internal error in regular expression engine I tried the same thing but with a smaller number of elements, say 1000 ftrlist[:1000], and then it worked. So I guess there is a bug on the scalability of the re engine when doing alternative searches. Attached I'm sending a tar ball that reproduces this. I'm gzipping it (hope sourceforge does not have a problem with the resulting binary file). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-09-09 10:04 Message: Logged In: YES user_id=38376 Alternative solution proposed; no response from submitter in ten months. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-12-11 14:39 Message: Logged In: YES user_id=38376 The SRE engine is usually compiled with 16-bit opcodes, which places a limit on the size of the compiled engine. Changing that to 32 bits might solve your problem... But in this case, I don't think one huge RE is really the best tool for the task; it's as easy (and much more efficient) to use an RE to *extract* the feature code, and use a dictionary to keep track of the ones you want to keep. (example: use re.sub("d+@(w[^|]+)|", callback, data) and let the callback look m.group(1) up in the dictionary; return m.group(0) if you want to keep the feature, "" if you don't). Hope this helps! </F> ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:35 Message: Logged In: YES user_id=576554 Ok, I give up on loading the file the size is restricted as one might have expected. If you want download the tar ball that would reproduce the error from www.let.rug.nl/~borges/ScalabilityREBug.tar.gz ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:31 Message: Logged In: YES user_id=576554 apparently sf does not want me to load tar balls... or I'm too dumb to do it. ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:24 Message: Logged In: YES user_id=576554 Problem with the file name the first time. Here is the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 From noreply at sourceforge.net Thu Sep 9 10:43:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 10:44:13 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 15:18 Message generated for change (Comment added) made by jiba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-09 08:43 Message: Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 21:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 12:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 11:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 10:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-19 22:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 15:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Thu Sep 9 12:52:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 12:54:00 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 03:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 10:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 09:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 03:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 12:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Sep 9 14:03:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 14:03:40 2004 Subject: [ python-Bugs-1024669 ] struct.calcsize() behaves strangely with short type Message-ID: Bugs item #1024669, was opened at 2004-09-08 22:00 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024669&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Serafeim Zanikolas (serzan) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize() behaves strangely with short type Initial Comment: Example: from struct import calcsize calcsize('h') reports 2 calcsize('i') reports 4, but calcsize('hi') reports 8! (same with calcsize('hhi')) Am I missing something or isn't it the case that calcsize('h') should report 4? python version: Python 2.3.3 (#1, May 25 2004, 16:51:30) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 uname -a output: Linux XXXX 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686 i686 i386 GNU/Linux ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-09 13:03 Message: Logged In: YES user_id=6656 struct defaults to "native" alignment. Try starting your format string with "=". This is documented, so closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024669&group_id=5470 From noreply at sourceforge.net Thu Sep 9 15:52:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 15:52:46 2004 Subject: [ python-Bugs-1025127 ] shutils.rmtree() uses excessive amounts of memory Message-ID: Bugs item #1025127, was opened at 2004-09-09 21:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: shutils.rmtree() uses excessive amounts of memory Initial Comment: The shutils.rmtree() implementation uses an excessive amount of memory when deleting large directory heirarchies. Before actually deleting any files, it builds up a list of (function, filename) tuples for all the files that it is going to remove. If there are a lot of files, this results in a lot of memory for a large heirarchy (I had a Python process using 800MB in one case). I'm not sure why it is doing things this way. It isn't using the list to avoid recursion, so the depth of directories it can remove is still limited by Python's recursion limit. Replacing _build_cmdtuple() with a generator might be a good way to reduce the memory usage while leaving the rest of the code unchanged. I checked in CVS, and this issue is still present on HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 From noreply at sourceforge.net Thu Sep 9 16:17:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 16:17:26 2004 Subject: [ python-Bugs-1025127 ] shutils.rmtree() uses excessive amounts of memory Message-ID: Bugs item #1025127, was opened at 2004-09-09 09:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: shutils.rmtree() uses excessive amounts of memory Initial Comment: The shutils.rmtree() implementation uses an excessive amount of memory when deleting large directory heirarchies. Before actually deleting any files, it builds up a list of (function, filename) tuples for all the files that it is going to remove. If there are a lot of files, this results in a lot of memory for a large heirarchy (I had a Python process using 800MB in one case). I'm not sure why it is doing things this way. It isn't using the list to avoid recursion, so the depth of directories it can remove is still limited by Python's recursion limit. Replacing _build_cmdtuple() with a generator might be a good way to reduce the memory usage while leaving the rest of the code unchanged. I checked in CVS, and this issue is still present on HEAD. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-09 10:17 Message: Logged In: YES user_id=31435 Rewrite it using os.walk() (not os.path.walk()) with topdown=False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 From noreply at sourceforge.net Thu Sep 9 22:37:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 22:37:26 2004 Subject: [ python-Bugs-977937 ] "build" target doesn't check umask Message-ID: Bugs item #977937, was opened at 2004-06-22 20:26 Message generated for change (Comment added) made by melicertes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977937&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: "build" target doesn't check umask Initial Comment: Normal procedure is to do "python setup.py build" as a non-root user, doing only "python setup.py install" as root. If the non-root user has a restrictive umask (i.e. 077), the built files will be mode 0600 (in directories created 0700), etc, and "setup.py install" will not make them world readable, so you end up with things like doc files installed mode 0600 in a new directory under /usr/share/doc/ that's mode 0700 and no one but root can read/use them. ---------------------------------------------------------------------- >Comment By: Charles (melicertes) Date: 2004-09-09 14:37 Message: Logged In: YES user_id=1064824 I guess I'll just manually set my umask before running distutils setup scripts. Not the most user-friendly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977937&group_id=5470 From noreply at sourceforge.net Thu Sep 9 22:41:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 22:41:17 2004 Subject: [ python-Bugs-1025392 ] HTML Documentation for 2.4a3 not found Message-ID: Bugs item #1025392, was opened at 2004-09-09 16:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: HTML Documentation for 2.4a3 not found Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Thu Sep 9 22:43:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 22:43:46 2004 Subject: [ python-Bugs-1025395 ] email.Utils.parseaddr fails to parse valid addresses Message-ID: Bugs item #1025395, was opened at 2004-09-09 14:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025395&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.parseaddr fails to parse valid addresses Initial Comment: email.Utils.parseaddr() does not successfully parse a field value into a (comment, address) pair if the address contains a source route with more than one hop. i.e., it is successfully parses this: "God" <@hop1.org:jeff@spec.org> to get the address , but it fails to do the same if supplied with a 2-hop source route: "God" <@hop1.org,@hop2.net:jeff@spec.org> In this case, it gets the comment ("God") right, but fails to extract the address. Multi-hop source routes, while deprecated, are still valid in rfc2822. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025395&group_id=5470 From noreply at sourceforge.net Fri Sep 10 00:59:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 00:59:50 2004 Subject: [ python-Bugs-932977 ] #!/usr/bin/python can find wrong python Message-ID: Bugs item #932977, was opened at 2004-04-11 00:34 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932977&group_id=5470 Category: Macintosh Group: None Status: Closed Resolution: Fixed Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: #!/usr/bin/python can find wrong python Initial Comment: It seems that in the event of a script run with #!/usr/bin/python MacOSX will not pass a full pathname as argv[0], but only "python". When getpath.c notices this situation it looks over $PATH to try and find python. But if it doesn't find the python from #!, or finds another one first, it will use that python as the basis for its sys.path setting. The darwinports folks have a fix for this: . ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2004-09-10 01:59 Message: Logged In: YES user_id=832344 The bug is stil present in Python 2.3.4, but there is a workaround, see http:/ /www.pythonmac.org/wiki/DuelingPythonsOnPanther ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-03 17:39 Message: Logged In: YES user_id=45365 Fixed in 1.47 and 1.46.14.1 by applying the darwinports fix. Thanks! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-04-16 01:10 Message: Logged In: YES user_id=45365 I think I agree that it is technically a darwin bug. But as a fix is available (use another means to get the pathname of the current executable if argv[0] seems bogus) I think we should put it in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-15 23:54 Message: Logged In: YES user_id=21627 Isn't that a Darwin bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932977&group_id=5470 From noreply at sourceforge.net Fri Sep 10 03:33:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 03:33:16 2004 Subject: [ python-Bugs-1025127 ] shutils.rmtree() uses excessive amounts of memory Message-ID: Bugs item #1025127, was opened at 2004-09-09 21:52 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: shutils.rmtree() uses excessive amounts of memory Initial Comment: The shutils.rmtree() implementation uses an excessive amount of memory when deleting large directory heirarchies. Before actually deleting any files, it builds up a list of (function, filename) tuples for all the files that it is going to remove. If there are a lot of files, this results in a lot of memory for a large heirarchy (I had a Python process using 800MB in one case). I'm not sure why it is doing things this way. It isn't using the list to avoid recursion, so the depth of directories it can remove is still limited by Python's recursion limit. Replacing _build_cmdtuple() with a generator might be a good way to reduce the memory usage while leaving the rest of the code unchanged. I checked in CVS, and this issue is still present on HEAD. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2004-09-10 09:33 Message: Logged In: YES user_id=146903 Attached is a Python file including a fixed up shutils.rmtree() using os.walk(). It seems to work for me, and should have the same error behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-09 22:17 Message: Logged In: YES user_id=31435 Rewrite it using os.walk() (not os.path.walk()) with topdown=False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 From noreply at sourceforge.net Fri Sep 10 04:14:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 04:14:54 2004 Subject: [ python-Bugs-1025525 ] asyncore.file_dispatcher should not take fd as argument Message-ID: Bugs item #1025525, was opened at 2004-09-10 12:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: david houlder (dhoulder) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore.file_dispatcher should not take fd as argument Initial Comment: Only relevant to posix. asyncore.file_dispatcher closes the file descriptor behind the file object, and not the file object itself. When another file gets opened, it gets the next available fd, which on posix, is the one just released by the close. Tested on python 2.2.3 on RedHat Enterprise Linux 3 and python 2.2.1 on HP Tru64 unix. See attached script for details and a solution. 'case 1' should show the problem regardless of the garbage collection strategy in python. 'case 2' relies on the file object being closed as soon as the last reference to it disappears, which seems to be the (current?) behaviour. [djh900@dh djh900]$ python file_dispatcher_bug.py case 1: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) firstPipe.read() says 'I am the second pipe\n' firstPipe.fileno()== 3 secondPipe.fileno()== 3 case 2: (Read 'I am the first pipe\n' from pipe) (pipe closing. fd== 3 ) (Read '' from pipe) secondPipe.fileno()== 3 dispatcher.secondPipe.read() says Traceback (most recent call last): File "file_dispatcher_bug.py", line 77, in ? print "dispatcher.secondPipe.read() says", repr(dispatcher.secondPipe.read()) IOError: [Errno 9] Bad file descriptor [djh900@dh djh900]$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&group_id=5470 From noreply at sourceforge.net Fri Sep 10 04:52:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 04:53:08 2004 Subject: [ python-Feature Requests-1025540 ] urllib2 http auth Message-ID: Feature Requests item #1025540, was opened at 2004-09-10 12:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1025540&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Nelson (wayland) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 http auth Initial Comment: Hi. I'd like it if urllib2 could use the https://user:password@host:port/ for HTTP Basic Authentication. Just for the record, my reason for wanting this is that RedHat's up2date depends on urllib2, and I want to use an authenticated up2date repository. This may not be the world's greatest way of achieving this end, but it seemed to me to be the simplest and most resuable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1025540&group_id=5470 From noreply at sourceforge.net Fri Sep 10 08:21:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 08:21:23 2004 Subject: [ python-Bugs-1025599 ] tkinter.py invalid number of parameter for _tkinet.create Message-ID: Bugs item #1025599, was opened at 2004-09-10 08:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bertrandbfr (bebel) Assigned to: Martin v. L?wis (loewis) Summary: tkinter.py invalid number of parameter for _tkinet.create Initial Comment: Python 2.4a3 (#1, Sep 9 2004, 21:26:33) [GCC 3.2.2] on linux2 File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) TypeError: function takes at most 4 arguments (8 given) this cause problem with skencil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 From noreply at sourceforge.net Fri Sep 10 08:36:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 08:36:37 2004 Subject: [ python-Bugs-1025599 ] tkinter.py invalid number of parameter for _tkinet.create Message-ID: Bugs item #1025599, was opened at 2004-09-10 08:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bertrandbfr (bebel) Assigned to: Martin v. L?wis (loewis) Summary: tkinter.py invalid number of parameter for _tkinet.create Initial Comment: Python 2.4a3 (#1, Sep 9 2004, 21:26:33) [GCC 3.2.2] on linux2 File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) TypeError: function takes at most 4 arguments (8 given) this cause problem with skencil ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:36 Message: Logged In: YES user_id=21627 Are you sure you are using the correct _tkinter module? _tkinter.create does take 8 arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 From noreply at sourceforge.net Fri Sep 10 08:37:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 08:38:19 2004 Subject: [ python-Bugs-1025392 ] HTML Documentation for 2.4a3 not found Message-ID: Bugs item #1025392, was opened at 2004-09-09 22:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) >Assigned to: Martin v. L?wis (loewis) Summary: HTML Documentation for 2.4a3 not found Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 09:10:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 09:11:01 2004 Subject: [ python-Bugs-1025392 ] HTML Documentation for 2.4a3 not found Message-ID: Bugs item #1025392, was opened at 2004-09-09 15:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Martin v. L?wis (loewis) Summary: HTML Documentation for 2.4a3 not found Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 02:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 01:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 10:01:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 10:01:24 2004 Subject: [ python-Bugs-1025392 ] HTML Documentation for 2.4a3 not found Message-ID: Bugs item #1025392, was opened at 2004-09-10 05:41 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Martin v. L?wis (loewis) Summary: HTML Documentation for 2.4a3 not found Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 17:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 16:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 15:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 10:39:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 10:40:15 2004 Subject: [ python-Bugs-1024427 ] WinCVS doesn't recognize 2.4a3 Message-ID: Bugs item #1024427, was opened at 2004-09-08 16:54 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 Category: None >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 7 Submitted By: David W. Thomas (davidwt) Assigned to: Martin v. L?wis (loewis) Summary: WinCVS doesn't recognize 2.4a3 Initial Comment: WinCVS does not recognize the alpha release of 2.4 after using the .msi installation of python. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 10:39 Message: Logged In: YES user_id=21627 This is not a bug in Python. WinCVS has python23.dll, python22.dll, python21.dll hard-coded, see common/PythonGlue.cpp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1024427&group_id=5470 From noreply at sourceforge.net Fri Sep 10 10:53:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 10:53:15 2004 Subject: [ python-Bugs-1025392 ] help() does not check for chm file Message-ID: Bugs item #1025392, was opened at 2004-09-09 22:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) >Assigned to: Nobody/Anonymous (nobody) >Summary: help() does not check for chm file Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 10:53 Message: Logged In: YES user_id=21627 I see. This is not a bug in IDLE, though - press F1, or select Help/Python Docs to see how IDLE does find the documentation. It is more a problem of the help() function, which does not know about the chm file; changing the subject accordingly. Notice that Python 2.4 has not been released yet, so there is no official HTML tarball. A prerelease HTML tarball is available from http://www.python.org/dev/doc/python-docs-devel.tar.bz2 Raymond, what versin of IDLE are you looking at? In the one shipped with 2.4a3 (IDLE 1.1a3), I see three menu entries: no Chm entry, but the "Python Docs F1" entry brings up the chm file. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 10:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 11:11:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 11:11:45 2004 Subject: [ python-Bugs-1025392 ] help() does not check for chm file Message-ID: Bugs item #1025392, was opened at 2004-09-09 22:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: help() does not check for chm file Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 11:11 Message: Logged In: YES user_id=21627 If anybody wants to tackle this issue: it is possible to decompile the chm into html files. I propose the following procedure: hh -decompile c:\python24\doc\html c:\python24 \python24.chm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 10:53 Message: Logged In: YES user_id=21627 I see. This is not a bug in IDLE, though - press F1, or select Help/Python Docs to see how IDLE does find the documentation. It is more a problem of the help() function, which does not know about the chm file; changing the subject accordingly. Notice that Python 2.4 has not been released yet, so there is no official HTML tarball. A prerelease HTML tarball is available from http://www.python.org/dev/doc/python-docs-devel.tar.bz2 Raymond, what versin of IDLE are you looking at? In the one shipped with 2.4a3 (IDLE 1.1a3), I see three menu entries: no Chm entry, but the "Python Docs F1" entry brings up the chm file. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 10:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 12:55:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 12:56:02 2004 Subject: [ python-Bugs-1025392 ] help() does not check for chm file Message-ID: Bugs item #1025392, was opened at 2004-09-10 05:41 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: help() does not check for chm file Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 19:55 Message: Logged In: YES user_id=671362 > Notice that Python 2.4 has not been released yet, so there is > no official HTML tarball. A prerelease HTML tarball is available > from > http://www.python.org/dev/doc/python-docs-devel.tar.bz2 It's my fault. I didn't know that. Thanks, Martin. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 18:11 Message: Logged In: YES user_id=21627 If anybody wants to tackle this issue: it is possible to decompile the chm into html files. I propose the following procedure: hh -decompile c:\python24\doc\html c:\python24 \python24.chm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 17:53 Message: Logged In: YES user_id=21627 I see. This is not a bug in IDLE, though - press F1, or select Help/Python Docs to see how IDLE does find the documentation. It is more a problem of the help() function, which does not know about the chm file; changing the subject accordingly. Notice that Python 2.4 has not been released yet, so there is no official HTML tarball. A prerelease HTML tarball is available from http://www.python.org/dev/doc/python-docs-devel.tar.bz2 Raymond, what versin of IDLE are you looking at? In the one shipped with 2.4a3 (IDLE 1.1a3), I see three menu entries: no Chm entry, but the "Python Docs F1" entry brings up the chm file. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 17:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 16:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 15:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 13:37:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 13:38:02 2004 Subject: [ python-Bugs-1025392 ] help() does not check for chm file Message-ID: Bugs item #1025392, was opened at 2004-09-09 16:41 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: help() does not check for chm file Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2004-09-10 07:37 Message: Logged In: YES user_id=285587 Thanks Martin. Also thanks to Raymond for his comments and to George for setting out the problem more clearly. Colin W. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 06:55 Message: Logged In: YES user_id=671362 > Notice that Python 2.4 has not been released yet, so there is > no official HTML tarball. A prerelease HTML tarball is available > from > http://www.python.org/dev/doc/python-docs-devel.tar.bz2 It's my fault. I didn't know that. Thanks, Martin. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 05:11 Message: Logged In: YES user_id=21627 If anybody wants to tackle this issue: it is possible to decompile the chm into html files. I propose the following procedure: hh -decompile c:\python24\doc\html c:\python24 \python24.chm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 04:53 Message: Logged In: YES user_id=21627 I see. This is not a bug in IDLE, though - press F1, or select Help/Python Docs to see how IDLE does find the documentation. It is more a problem of the help() function, which does not know about the chm file; changing the subject accordingly. Notice that Python 2.4 has not been released yet, so there is no official HTML tarball. A prerelease HTML tarball is available from http://www.python.org/dev/doc/python-docs-devel.tar.bz2 Raymond, what versin of IDLE are you looking at? In the one shipped with 2.4a3 (IDLE 1.1a3), I see three menu entries: no Chm entry, but the "Python Docs F1" entry brings up the chm file. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 04:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 03:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 02:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 10 14:00:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 14:00:19 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-03 20:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 7 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 14:00 Message: Logged In: YES user_id=21627 This should be fixed in msi.py 1.10. Please try the installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4a3.3.msi ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 20:09 Message: Logged In: YES user_id=21627 I see. Until yesterday, I didn't even know you can use the open verb in contexts other than double-clicking. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-08 17:14 Message: Logged In: YES user_id=671362 Hi, Martin. Your fix doesn't look enough for me. I tried a new installer but noticed that all command-line argumetns(install, --help, etc) are ignored. I think adding %* after "%1" is necessary. Then the file association to *.py files looks like: "C:\Python24\python.exe" "%1" %* or "C:\Python24\python.exe" -console "%1" %* # CVS HEAD Thanks in advance. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 11:01 Message: Logged In: YES user_id=21627 Thanks for your report. I have re-rolled the package, and Anthony has made it available from http://www.python.org/ftp/python/2.4/python-2.4a3.2.msi I will commit the changes to msi.py shortly. I have left the Itanium installer untouched - Itanium users will either fix the extensions themselves, or wait for 2.4b1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-04 06:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 03:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 01:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Fri Sep 10 14:10:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 14:10:49 2004 Subject: [ python-Bugs-644744 ] bdist_rpm fails when installing man pages Message-ID: Bugs item #644744, was opened at 2002-11-27 15:30 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644744&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm fails when installing man pages Initial Comment: When a man page is in data_files, the rpm installer compresses it with gzip (done by the brp-compress script). I attached a little hack for install_data command to add a ".gz" to such man pages. Then it works for me. Of course, the proper fix would be to detect if brp-compress is run and what files were compressed by the script. But I am not an rpm guru, so its up to you how you want to fix it. I am using a Debian Linux unstable boxen with Python 2.2.2-2, and rpm 4.0.4-11 ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2004-09-10 14:10 Message: Logged In: YES user_id=9205 Finally I got around to investigate this a little more. What essentially happens is this: 1) bdist_rpm generates a .spec file with the following install command: python setup.py install --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES .. and the following files section %files -f INSTALLED_FILES 2) if the setup.py installed any man pages, then after %install and before %files rpm runs brp-compress (usually found in /usr/lib/rpm/brp-compress) which compresses all man pages with gzip. 3) Now the man pages have a '.gz' suffix, but the INSTALLED_FILES file lists them still without the suffix. The %files section of the rpm .spec file will fail. The solution in my case was to use a custom rpm-install script configured with setup.cfg: [bdist_rpm] install_script = install-rpm.sh The install-rpm.sh file is attached. The solution is not very generic - brp-compress compresses a lot more files than the install-rpm.sh detects. But at least there should be a documentation somewhere about the brp-compress pitfall. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644744&group_id=5470 From noreply at sourceforge.net Fri Sep 10 15:53:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 15:53:41 2004 Subject: [ python-Bugs-1025872 ] X to the power of 0 may give wrong answer Message-ID: Bugs item #1025872, was opened at 2004-09-10 23:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025872&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: X to the power of 0 may give wrong answer Initial Comment: According to Python 2.3 and 2.4, -1 ** 0 = -1 ! It appears to do this for any negative value. The answer to x ** 0 should be 1, regardless of the sign of x. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025872&group_id=5470 From noreply at sourceforge.net Fri Sep 10 15:55:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 15:56:21 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-10 14:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 17:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Fri Sep 10 16:00:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 16:00:30 2004 Subject: [ python-Bugs-1025872 ] X to the power of 0 may give wrong answer Message-ID: Bugs item #1025872, was opened at 2004-09-10 23:53 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025872&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: X to the power of 0 may give wrong answer Initial Comment: According to Python 2.3 and 2.4, -1 ** 0 = -1 ! It appears to do this for any negative value. The answer to x ** 0 should be 1, regardless of the sign of x. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-11 00:00 Message: Logged In: YES user_id=1038590 The plot thickens. . . if I use the operator module, it works: Python 2.3.4 (#1, Jun 15 2004, 21:38:43) [GCC 3.4.0 20040613 (Red Hat Linux 3.4.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> -4.3 ** 0 -1.0 >>> from operator import __pow__ >>> __pow__(-1, 0) 1 >>> -1 ** 0 -1 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025872&group_id=5470 From noreply at sourceforge.net Fri Sep 10 16:07:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 16:08:52 2004 Subject: [ python-Bugs-1025872 ] X to the power of 0 may give wrong answer Message-ID: Bugs item #1025872, was opened at 2004-09-10 09:53 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025872&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: X to the power of 0 may give wrong answer Initial Comment: According to Python 2.3 and 2.4, -1 ** 0 = -1 ! It appears to do this for any negative value. The answer to x ** 0 should be 1, regardless of the sign of x. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-10 10:07 Message: Logged In: YES user_id=31435 Precedence. From the language ref: "The power operator binds more tightly than unary operators on its left; it binds less tightly than unary operators on its right.". Python doesn't have negative numeric literals. -1 is the unary minus operator applied to the positive literal 1. So -1**0 parses as -(1**0) and -1 is the correct result. Add parens if you want a different evaluation order: >>> (-1)**0 1 >>> ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-10 10:00 Message: Logged In: YES user_id=1038590 The plot thickens. . . if I use the operator module, it works: Python 2.3.4 (#1, Jun 15 2004, 21:38:43) [GCC 3.4.0 20040613 (Red Hat Linux 3.4.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> -4.3 ** 0 -1.0 >>> from operator import __pow__ >>> __pow__(-1, 0) 1 >>> -1 ** 0 -1 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025872&group_id=5470 From noreply at sourceforge.net Fri Sep 10 16:22:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 16:22:06 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 04:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 08:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 11:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 06:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Fri Sep 10 16:37:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 16:38:04 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 15:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 14:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 17:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Fri Sep 10 20:47:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 20:47:52 2004 Subject: [ python-Bugs-1025599 ] tkinter.py invalid number of parameter for _tkinet.create Message-ID: Bugs item #1025599, was opened at 2004-09-10 08:21 Message generated for change (Comment added) made by bebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bertrandbfr (bebel) Assigned to: Martin v. L?wis (loewis) Summary: tkinter.py invalid number of parameter for _tkinet.create Initial Comment: Python 2.4a3 (#1, Sep 9 2004, 21:26:33) [GCC 3.2.2] on linux2 File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) TypeError: function takes at most 4 arguments (8 given) this cause problem with skencil ---------------------------------------------------------------------- >Comment By: bertrandbfr (bebel) Date: 2004-09-10 20:47 Message: Logged In: YES user_id=1119278 Oooh i'm sorry the guilty is skencil-0.6.16 who redefine Tkinter_Create with only four parameters in paxtkinter.c shame on me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:36 Message: Logged In: YES user_id=21627 Are you sure you are using the correct _tkinter module? _tkinter.create does take 8 arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 From noreply at sourceforge.net Fri Sep 10 20:52:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 20:52:57 2004 Subject: [ python-Bugs-1026038 ] "ASCII" in doc section "String literals" Message-ID: Bugs item #1026038, was opened at 2004-09-10 20:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026038&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "ASCII" in doc section "String literals" Initial Comment: Section '2.4.1 String literals' says that shortstringchar and longstringchar are ASCII characters. This is wrong, however, because non-ASCII characters are allowed as well. The documentation of \xhh and \ooo (in the same section) says that they represent ASCII characters. It seems to me that they actually represent ISO-8859-1 characters (which is important if these escape sequences occur in a unicode string literal). Is that the intended behavior, by the way? Shouldn't it rather depend on the -*- coding -*- of the source file? Maybe also add a reference to PEP 263? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026038&group_id=5470 From noreply at sourceforge.net Fri Sep 10 21:35:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 21:35:40 2004 Subject: [ python-Bugs-1023359 ] Example does not match diagram. Message-ID: Bugs item #1023359, was opened at 2004-09-06 19:43 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023359&group_id=5470 Category: Documentation Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: A.M. Kuchling (akuchling) Summary: Example does not match diagram. Initial Comment: The PEP describing the new type system changes in v2.2 introduces an inheritance diagram to illustrate a problem. After introducing the problem and solution, the "super" function is introduced. After that, a code example shows a use of super for the case in the diagram. The bug is that the inheritance shown in the diagram is not in the code, and the class definition should read "class D (B, C):" instead of "class D:". This is seen at: http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-09-10 15:35 Message: Logged In: YES user_id=11375 Fixed in CVS HEAD; will backport to the 2.2 and 2.3 maintenance branches. It's unlikely anyone will regenerate the 2.2 HTML docs, though. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023359&group_id=5470 From noreply at sourceforge.net Fri Sep 10 22:30:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 10 22:31:43 2004 Subject: [ python-Bugs-1025599 ] tkinter.py invalid number of parameter for _tkinet.create Message-ID: Bugs item #1025599, was opened at 2004-09-10 08:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 Category: Tkinter Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: bertrandbfr (bebel) Assigned to: Martin v. L?wis (loewis) Summary: tkinter.py invalid number of parameter for _tkinet.create Initial Comment: Python 2.4a3 (#1, Sep 9 2004, 21:26:33) [GCC 3.2.2] on linux2 File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", line 1569, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) TypeError: function takes at most 4 arguments (8 given) this cause problem with skencil ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 22:30 Message: Logged In: YES user_id=21627 Closing this as invalid. ---------------------------------------------------------------------- Comment By: bertrandbfr (bebel) Date: 2004-09-10 20:47 Message: Logged In: YES user_id=1119278 Oooh i'm sorry the guilty is skencil-0.6.16 who redefine Tkinter_Create with only four parameters in paxtkinter.c shame on me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:36 Message: Logged In: YES user_id=21627 Are you sure you are using the correct _tkinter module? _tkinter.create does take 8 arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025599&group_id=5470 From noreply at sourceforge.net Sat Sep 11 01:18:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 01:18:57 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Sat Sep 11 03:18:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 03:18:55 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 08:25 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-08 19:52 Message: Logged In: YES user_id=185428 I guess so even though 2.4 is still alpha. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 14:56 Message: Logged In: YES user_id=80475 So, can this be closed as "out-of-date"? ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=185428 Tested with the alpha version Python-2.4a3. It works properly! ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-26 07:26 Message: Logged In: YES user_id=185428 I did not find the file 'thread_pthread.h' under my installation :-(. My program in C is: ---------------------------------------------------------- #include #include #include void *ExecuteCommand( void *ptr ) { char *command = ptr; int result = system(command); printf("Tested the command: %s; result = %d\n",command,result); return NULL; } int main() { pthread_t thread; pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_04/bin/java -cp . DoNothing"); pthread_join(thread,NULL); pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_05/bin/java -cp . DoNothing"); pthread_join(thread,NULL); return 0; } ---------------------------------------------------------- It correctly prints 0 for both threads. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-26 00:37 Message: Logged In: YES user_id=33168 There's another possibility, but I'm not sure if it would affect your build or not. It's possible to set a smaller stack size when creating a thread. This would mean that THREAD_STACK_SIZE is set. If you look in ./Python/thread_pthread.h you will see the references. THREAD_STACK_SIZE is not set on my box. In your C test, did you pass NULL for the attributes or did you do pthread_attr_init(). It's possible that is the difference between your C test and python. You might try mucking in ./Python/thread_pthread.h to see if you can determine what is happening. ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 20:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 18:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Sat Sep 11 03:55:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 03:55:44 2004 Subject: [ python-Bugs-1022010 ] wrong options are set to python.exe Message-ID: Bugs item #1022010, was opened at 2004-09-04 03:46 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 Category: Installation Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: George Yoshida (quiver) Assigned to: Martin v. L?wis (loewis) Summary: wrong options are set to python.exe Initial Comment: When I tried to run a script(just double-clicked it) with Python 2.4 on Win 2000, I ran into an error message: C:\WINNT\system32\cmd.exe /c test.py Unknown option: -n usage: C:\Python24\python.exe [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. shell returned 2 Hit any key to close this window... The problem seems to be the associations of Python related file types. In this case, "Python file" (Extension is ".py") is associated with two actions: - Edit with IDLE - open (default) If you look at the "Application used to perform action" text box of 'open', you can see: "C:\Python24\python.exe" -n -e "%1" But neither -n nor -e is a valid option for python.exe and it results in an error message. These options are for IDLE! Line #1016 to #1020 of mis.py may be relevant to this. # Tools/msi/mis.py # add_data(db, "MIME") XXX add_data(db, "Verb", [("py", "open", 1, None, r'-n -e "%1"'), ("pyw", "open", 1, None, r'-n -e "%1"'), ("pyc", "open", 1, None, r'-n -e "%1"'), ("pyo", "open", 1, None, r'-n -e "%1"')]) ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2004-09-11 10:55 Message: Logged In: YES user_id=671362 Looks fine to me. FWI, the new installer made the associations on my PC as follows: "C:\Python24\pythonw.exe" "C:\Python24\Lib\idlelib\idle.pyw" - n -e "%1" - py(Edit with Idle) - pyw(Edit with Idle) "C:\Python24\pythonw.exe" "%1" %* - py(open) - pyc(open) - pyo(open) - pyw(open) Many thanks for your work. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 21:00 Message: Logged In: YES user_id=21627 This should be fixed in msi.py 1.10. Please try the installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4a3.3.msi ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-09 03:09 Message: Logged In: YES user_id=21627 I see. Until yesterday, I didn't even know you can use the open verb in contexts other than double-clicking. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-09 00:14 Message: Logged In: YES user_id=671362 Hi, Martin. Your fix doesn't look enough for me. I tried a new installer but noticed that all command-line argumetns(install, --help, etc) are ignored. I think adding %* after "%1" is necessary. Then the file association to *.py files looks like: "C:\Python24\python.exe" "%1" %* or "C:\Python24\python.exe" -console "%1" %* # CVS HEAD Thanks in advance. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 18:01 Message: Logged In: YES user_id=21627 Thanks for your report. I have re-rolled the package, and Anthony has made it available from http://www.python.org/ftp/python/2.4/python-2.4a3.2.msi I will commit the changes to msi.py shortly. I have left the Itanium installer untouched - Itanium users will either fix the extensions themselves, or wait for 2.4b1. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-04 13:20 Message: Logged In: YES user_id=671362 Sorry for not being clearer. I meant Python 2.4a3 by Python 2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-04 10:04 Message: Logged In: YES user_id=31435 He's using the 2.4a3 just released; a number of reports like this appeared on c.l.py soon after the release, and George was the first to do the right thing about it . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-04 08:25 Message: Logged In: YES user_id=21627 Python 2.4 has not been released yet. What precisely have you been using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022010&group_id=5470 From noreply at sourceforge.net Sat Sep 11 12:13:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 12:13:38 2004 Subject: [ python-Bugs-1026269 ] Confusing error message when subclassing from invalid base Message-ID: Bugs item #1026269, was opened at 2004-09-11 12:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026269&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing error message when subclassing from invalid base Initial Comment: In Python 2.3, subclassing from bool resulted in: >>> class Test(bool): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: type 'bool' is not an acceptable base type In Python2.4a3 (latest CVS), it results in: >>> class Test(bool): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: Error when calling the metaclass. Make sure the base arguments are valid. Interestingly, also in Python 2.4a3: >>> type("foo", (bool,), {}) Traceback (most recent call last): File "", line 1, in ? TypeError: type 'bool' is not an acceptable base type I think it is a bug, and the error message should be 'not an acceptable base type'. Apart from that, I don't see why it is not an acceptable base type, but that's a different issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026269&group_id=5470 From noreply at sourceforge.net Sat Sep 11 12:15:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 12:16:11 2004 Subject: [ python-Bugs-1026269 ] Confusing error message when subclassing from invalid base Message-ID: Bugs item #1026269, was opened at 2004-09-11 12:13 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026269&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing error message when subclassing from invalid base Initial Comment: In Python 2.3, subclassing from bool resulted in: >>> class Test(bool): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: type 'bool' is not an acceptable base type In Python2.4a3 (latest CVS), it results in: >>> class Test(bool): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: Error when calling the metaclass. Make sure the base arguments are valid. Interestingly, also in Python 2.4a3: >>> type("foo", (bool,), {}) Traceback (most recent call last): File "", line 1, in ? TypeError: type 'bool' is not an acceptable base type I think it is a bug, and the error message should be 'not an acceptable base type'. Apart from that, I don't see why it is not an acceptable base type, but that's a different issue. ---------------------------------------------------------------------- >Comment By: Gerrit Holl (gerrit) Date: 2004-09-11 12:15 Message: Logged In: YES user_id=13298 This seems to be related to: [ 1014215 ] Unspecific errors with metaclass http://www.python.org/sf/1014215 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026269&group_id=5470 From noreply at sourceforge.net Sat Sep 11 17:08:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 17:09:08 2004 Subject: [ python-Bugs-1026038 ] "ASCII" in doc section "String literals" Message-ID: Bugs item #1026038, was opened at 2004-09-10 20:52 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026038&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "ASCII" in doc section "String literals" Initial Comment: Section '2.4.1 String literals' says that shortstringchar and longstringchar are ASCII characters. This is wrong, however, because non-ASCII characters are allowed as well. The documentation of \xhh and \ooo (in the same section) says that they represent ASCII characters. It seems to me that they actually represent ISO-8859-1 characters (which is important if these escape sequences occur in a unicode string literal). Is that the intended behavior, by the way? Shouldn't it rather depend on the -*- coding -*- of the source file? Maybe also add a reference to PEP 263? ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-11 17:08 Message: Logged In: YES user_id=1014490 > The documentation of \xhh and \ooo (in the same > section) says that they represent ASCII characters. It > seems to me that they actually represent ISO-8859-1 > characters (which is important if these escape > sequences occur in a unicode string literal). Correction: They represent bytes in normal strings and \u00xx in unicode strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026038&group_id=5470 From noreply at sourceforge.net Sat Sep 11 18:07:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 18:08:03 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-18 03:24 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Amit Aronovitch (amitar) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 18:07 Message: Logged In: YES user_id=469548 Gee Brett, thanks! I'm just going to agree with you though, the patch is too much trouble. I've made one small change (use __module__ for functions/methods too) which ensures there's only a problem when you're both using multiple hard links to one file (rather unlikely) *and* you're calling inspect.getmodule on a traceback, frame or code object (not all that likely either). ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-09-06 23:14 Message: Logged In: YES user_id=564711 Your'e the maintainers. I'll have to live with whatever you decide, but I still feel I must bring my knowledge/arguments to your attention. Basicly, i believe that providing an os.path.fileid function is more "correct" conceptually as opposed to 'realpath' (have a look at the implementation of the 'samefile' function in the pre-my-patch version of posixpath.py - shouldn't this be generalizable?), so would probably be more resistant to future bugs. (The specific problem that made me notice this bug would probably be solved by Johannes' patch, but problems could appear elsewhere for other people.) re: "... filesystem in an uncommon way" - a) You may still want to use python on systems where you dont have much control over the way your sysadmin organises the filesystem. b) Some systems have complex multi-platform network filesystems. Different platforms share the crossplatform files of the installation. It becomes necessary to use links to keep it managable (though I believe symlinks should almost always be enough). re: "'help' is just..." - Well, as I said before, the problem is really with *inspect*. This is a rather general purpose module, and bad things might happen if you get this unexpected 'None' output from inspect.getmodule re: "... the patch touches so many files" - This is the nature of the current os.path implementation. The common interface is reimplemented for each platform. For example, the "realpath" function has a default no-op implementation, which is repeated in many of the *path.py (p.s., I believe the 'realpath' function was added because people actually needed something like my fileid function, but missed the generalization - unique ID does not always have to be a PATH). I could have provided a default in the common os.py code, but decided this kind of implementation would be inconsistent with current module's style. If you think otherwise - I can provide such alternative. p.s. - I would appreciate a reply about my 'inspect.getabsfile' question - I believe functions should either be documented or used only internally (otherwise you can't change internal implementation without breaking external code). p.s. 2 - I'm uploading an up-to-date diff p.s. 3 - If you think this kind of conversation is inappropriate for the bts - pls let me know - you can use personal email. tks ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-05 21:53 Message: Logged In: YES user_id=357491 Reassigning to Johannes since he has checkin rights now. =) But honestly I think this bug is just not worth the hassle. This is only an issue if you are futzing with your file system in an uncommon way. 'help' is just for quick checks and thus if doesn't work for *every* situation it isn't going to be the end of the world. Plus I don't like how the patch touches so many files with the same chunk of code. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-08-29 15:02 Message: Logged In: YES user_id=564711 Pls see attached files. Note that jlgijsbers' patch does not resolve the full scope of the problem as described in my original post (see the "discussion" part) - namely: it only works for symbolic links. bcannon (re 12/7 msg): Sorry. I wrote the long explanations in hope it would save you time, but it seems they were not clear enough. To avoid trouble repeating the problem, this time I'll provide a shell script for testing it. Also provided is a proposed patch (against cvs snapshot from 29 Aug 2004). About the patch ----------------- I added a "fileid" function to os.path (as suggested in my original post). This means macpath os2emxpath and ntpath had to be touched as well as posixpath. (libposixpath.tex would also need an update if you decide to adopt this patch) Question about inspect.getabsfile ----------------------------------- I'm not sure if this function is ment to be an "internal use" or "interface" function. It does not appear in the module's documentation (libinspect.tex), but the pydoc module still uses it (and as far as I could see - it's the only module that uses it). After my patch, getabsfile is not used internally by inspect anymore, so should be deleted if "internal use". The use of this function in pydoc is for human readable output, so I don't think it's really necessary there (I think there's no need to do "normcase" there). tks for yr attention ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 20:47 Message: Logged In: YES user_id=357491 Checked in as rev. 1.52 for 'inspect'. Not going to backport since it is a semantic change. Thanks for the patch, Johannes. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 19:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-13 02:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-13 00:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 20:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 22:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 04:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Sat Sep 11 19:34:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 19:34:16 2004 Subject: [ python-Bugs-1022152 ] Bad examples of gettext.translation Message-ID: Bugs item #1022152, was opened at 2004-09-04 01:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022152&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Bad examples of gettext.translation Initial Comment: The usage examples on "6.27.3.3 Changing languages on the fly" (http://www.python.org/dev/doc/devel/lib/node293.html) are incorrect, because of the syntax of gettext.translation. The examples just don't match "6.27.2 Class-based API" (http://www.python.org/dev/doc/devel/lib/node285.html), and they gave me an error when tried them:the "domain" is not optional. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 19:34 Message: Logged In: YES user_id=469548 Fixed by applying patch #1024238. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-08 11:24 Message: Logged In: YES user_id=625864 Same issue here when I tried it. I've created patch #1024238 to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1022152&group_id=5470 From noreply at sourceforge.net Sat Sep 11 23:28:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 23:28:37 2004 Subject: [ python-Bugs-1026480 ] iso-latin-1 strings and functions lower & upper Message-ID: Bugs item #1026480, was opened at 2004-09-11 18:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026480&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: iso-latin-1 strings and functions lower & upper Initial Comment: I have no problems in Python in using strings which contain accented letters (my Emacs has no problems in producing them using one-byte iso-8859-1 encoding). However functions 'lower' and 'upper' do not work properly on these letters as shown below (I hope all accents appear properly within your browsers): ------------------------------------------------------------- as = "a?????" # except for the first 'a', all other have accents AS = "A?????" # except for the first 'A', all other have accents print "direct: %s -- %s" % (as, AS) print "lower: %s -- %s" % (as.lower(), AS.lower()) print "upper: %s -- %s" % (as.upper(), AS.upper()) ------------------------------------------------------------- The output is: -------------------------------------------------------------- direct: a????? -- A????? lower: a????? -- a????? upper: A????? -- A????? -------------------------------------------------------------- i.e., accented letters (above 128) are not translated. It did not make any difference to put the line # -*- coding: iso-latin-1 -*- about the encoding as recommended by PEP 0263. I am not sure whether this is a bug or it is intentional, i.e. these functions work only for pure ASCII letters. However it is a major inconvenience for those who use any language which is not English but uses the Latin aplphabet :-(. There should be some mechanism to signal these functions which Latin variant (iso-8859-1, iso-8859-2, ...) is being used, so that they behave properly; eg, optional second argument? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026480&group_id=5470 From noreply at sourceforge.net Sat Sep 11 23:36:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 23:42:45 2004 Subject: [ python-Bugs-1025127 ] shutils.rmtree() uses excessive amounts of memory Message-ID: Bugs item #1025127, was opened at 2004-09-09 15:52 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) >Assigned to: Tim Peters (tim_one) Summary: shutils.rmtree() uses excessive amounts of memory Initial Comment: The shutils.rmtree() implementation uses an excessive amount of memory when deleting large directory heirarchies. Before actually deleting any files, it builds up a list of (function, filename) tuples for all the files that it is going to remove. If there are a lot of files, this results in a lot of memory for a large heirarchy (I had a Python process using 800MB in one case). I'm not sure why it is doing things this way. It isn't using the list to avoid recursion, so the depth of directories it can remove is still limited by Python's recursion limit. Replacing _build_cmdtuple() with a generator might be a good way to reduce the memory usage while leaving the rest of the code unchanged. I checked in CVS, and this issue is still present on HEAD. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 23:36 Message: Logged In: YES user_id=469548 Please attach changes as a patch next time. I've attached shutils-rmtree.py as a patch this time. I gave it a quick review and added a test to test_shutil.py to ensure some not-very-obvious behavior (don't delete a path passed to rmtree if it's a file) would be preserved. The new version seems fine to me. Tim, could you take a look at it as well? ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2004-09-10 03:33 Message: Logged In: YES user_id=146903 Attached is a Python file including a fixed up shutils.rmtree() using os.walk(). It seems to work for me, and should have the same error behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-09 16:17 Message: Logged In: YES user_id=31435 Rewrite it using os.walk() (not os.path.walk()) with topdown=False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 From noreply at sourceforge.net Sun Sep 12 00:56:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 01:03:06 2004 Subject: [ python-Bugs-1025127 ] shutils.rmtree() uses excessive amounts of memory Message-ID: Bugs item #1025127, was opened at 2004-09-09 09:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: shutils.rmtree() uses excessive amounts of memory Initial Comment: The shutils.rmtree() implementation uses an excessive amount of memory when deleting large directory heirarchies. Before actually deleting any files, it builds up a list of (function, filename) tuples for all the files that it is going to remove. If there are a lot of files, this results in a lot of memory for a large heirarchy (I had a Python process using 800MB in one case). I'm not sure why it is doing things this way. It isn't using the list to avoid recursion, so the depth of directories it can remove is still limited by Python's recursion limit. Replacing _build_cmdtuple() with a generator might be a good way to reduce the memory usage while leaving the rest of the code unchanged. I checked in CVS, and this issue is still present on HEAD. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-11 18:56 Message: Logged In: YES user_id=31435 I don't really have time for a thorough review. I'll note that stuff like func = something1 arg = something2 func(arg) looks, to my eye, like a convoluted way to say something1(something2) I suppose that's to keep the onerror= gimmick working, though. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 17:36 Message: Logged In: YES user_id=469548 Please attach changes as a patch next time. I've attached shutils-rmtree.py as a patch this time. I gave it a quick review and added a test to test_shutil.py to ensure some not-very-obvious behavior (don't delete a path passed to rmtree if it's a file) would be preserved. The new version seems fine to me. Tim, could you take a look at it as well? ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2004-09-09 21:33 Message: Logged In: YES user_id=146903 Attached is a Python file including a fixed up shutils.rmtree() using os.walk(). It seems to work for me, and should have the same error behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-09 10:17 Message: Logged In: YES user_id=31435 Rewrite it using os.walk() (not os.path.walk()) with topdown=False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025127&group_id=5470 From noreply at sourceforge.net Sun Sep 12 05:25:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 05:26:01 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-11 23:25 Message: Logged In: YES user_id=31435 Zope3's problem w/ asyncore appears to be fixed. Thanks! WRT > Therefore, I think the 'if is_r or is_w' logic is necessary. I expect you're right. I think I had vaguely in mind that "the usual" implementation of fdsets represents them as bit vectors, so that redundancy wouldn't hurt. But that's not the only part of the story, and I overlooked that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 10:08 Message: Logged In: YES user_id=11375 Original patch committed as rev. 1.61 of asyncore.py. I'm leaving the bug open until Tim (or someone) reports that the problem is fixed. poll2 (the one that uses select.poll()) should automatically remove objects for which POLLNVAL is set -- that's what the error means, after all. I'll worry about that after 2.3alpha3 is released. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 09:32 Message: Logged In: YES user_id=11375 'e = r+w' means 'e' can contain the same descriptor twice, if it's both readable and writable, and I think this matters. Duplicate fd's don't cause a problem with the select() system call itself, but the return value from select.select() would include the file descriptor twice. (I've attached a test program that demonstrates this for readable fds.) Therefore, I think the 'if is_r or is_w' logic is necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:49 Message: Logged In: YES user_id=31435 Logic similar to the logic in the patch worked for me when I tried it. Suggest it would be faster and clearer to just add e = r + w to the 2.3 asyncore poll(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 12:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Sun Sep 12 05:40:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 05:40:59 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 16:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-11 23:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 19:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 18:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 18:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 18:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 17:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 15:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 20:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 19:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 18:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Sun Sep 12 16:22:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 16:22:19 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 10:33 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 15:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 14:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 17:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Sun Sep 12 16:22:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 16:22:44 2004 Subject: [ python-Bugs-1026269 ] Confusing error message when subclassing from invalid base Message-ID: Bugs item #1026269, was opened at 2004-09-11 11:13 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026269&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Michael Hudson (mwh) Summary: Confusing error message when subclassing from invalid base Initial Comment: In Python 2.3, subclassing from bool resulted in: >>> class Test(bool): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: type 'bool' is not an acceptable base type In Python2.4a3 (latest CVS), it results in: >>> class Test(bool): pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: Error when calling the metaclass. Make sure the base arguments are valid. Interestingly, also in Python 2.4a3: >>> type("foo", (bool,), {}) Traceback (most recent call last): File "", line 1, in ? TypeError: type 'bool' is not an acceptable base type I think it is a bug, and the error message should be 'not an acceptable base type'. Apart from that, I don't see why it is not an acceptable base type, but that's a different issue. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-12 15:22 Message: Logged In: YES user_id=6656 Yeah, it's the same. Closing as duplicate. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-09-11 11:15 Message: Logged In: YES user_id=13298 This seems to be related to: [ 1014215 ] Unspecific errors with metaclass http://www.python.org/sf/1014215 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026269&group_id=5470 From noreply at sourceforge.net Sun Sep 12 20:55:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 20:55:47 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 11:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 20:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Mon Sep 13 04:55:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 04:56:00 2004 Subject: [ python-Bugs-738361 ] crash error in glob.glob; directories with brackets Message-ID: Bugs item #738361, was opened at 2003-05-15 12:06 Message generated for change (Settings changed) made by progoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 Category: Extension Modules Group: Python 2.2.2 >Status: Deleted Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: crash error in glob.glob; directories with brackets Initial Comment: I'm attaching a zip file containing a python file and directory structure to test this. I ran into this bug in real life work, so, as contrived as the bug test may look, it happens. I was writing a function which recurses through directories and does stuff with the files it finds. glob.glob() doesn't return any files inside a directory named [_] glob.glob() crashes on a directory named [A--_B]. I tried a few different combinations of characters inside brackets, but this was the only one I could get it to crash on. the crash happens during the regular expression compilation, as probably can be surmised by seeing the characters which cause it ( [] ). it also may be a combination of that and using \ as the directory delimiter since this is win32. File "C:\temp\globbug\bug.py", line 5, in test fs = glob.glob( path + '\*' ) File "C:\Python22\lib\glob.py", line 24, in glob list = glob(dirname) File "C:\Python22\lib\glob.py", line 37, in glob sublist = glob1(dirname, basename) File "C:\Python22\lib\glob.py", line 50, in glob1 return fnmatch.filter(names,pattern) File "C:\Python22\lib\fnmatch.py", line 47, in filter _cache[pat] = re.compile(res) File "C:\Python22\lib\sre.py", line 179, in compile return _compile(pattern, flags) File "C:\Python22\lib\sre.py", line 229, in _compile raise error, v # invalid expression sre_constants.error: bad character range ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-17 19:43 Message: Logged In: YES user_id=31435 The heart of the problem seems to be the comment in fnmatch.py's translate() docstring: """Translate a shell PATTERN to a regular expression. There is no way to quote meta-characters. """ So it looks like an undocumented design limitation. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-16 15:32 Message: Logged In: YES user_id=61663 So a co-worker pointed out that you could have directorys like mine, but say, numbered: [A--_B]1 [A--_B]2 etc say you wanted a pattern like '[A--_B]?' to get them all....that's not a valid directory, so it definitely needs to do some wildcard expansion...but it doesn't need to mess with what's inside the brackets. fnmatch probably shouldn't throw an exception in any case...regardless, we're of the opinion that the only logical way around this issue of wildcard characters in filenames is to have the programmer escape stuff manually. so r"\[A--_B]?" would be what is needed. python/glob/fnmatch can't read the programmer's mind in a pattern with wildcards which ones are supposed to be pattern or not. to take this route, fnmatch would have to be modified to recognize characters that are \-escaped, because it doesn't at the moment. or maybe that's not the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 14:20 Message: Logged In: YES user_id=80475 Okay. See if you can come-up with a more elegant patch that only touches the glob module. If you can see a straight-forward way to test it, then some unittests would be nice also. ---------------------------------------------------------------------- Comment By: Steven Scott (progoth) Date: 2003-05-16 00:41 Message: Logged In: YES user_id=61663 brackets are valid file/dir names in unix, too. in fact, if I'm not mistaken, the only 2 characters not allowed in unix file names are / and \0. I don't see how it's not a bug if glob tries to read the files in a directory that exists and crashes (or doesn't read them). as for how it should be fixed, I have no idea. my patch isn't very elegant. btw, I just ran this on unix (after changing the \ to / in the test script) and the exact same behavior was exhibited. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-16 00:24 Message: Logged In: YES user_id=80475 This doesn't seem like a bug to me. Those strange names have the Unix style magic characters in them. Unfortunately, brackets are valid file/dir names in Windows. If anything were changed, I would prefer strengthening the magic character recognizer from: magic_check = re.compile('[*?[]') to something that can treat ill-formed bracket expressions as being non-magic. When posting a bug report, please avoid zip files and multiple test scripts. It is enough to include in the text of the report something like this: glob.glob('[_]/*') # fails to recognize a win directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738361&group_id=5470 From noreply at sourceforge.net Mon Sep 13 06:18:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 06:18:37 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 04:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-12 23:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 09:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 08:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 11:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 06:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Mon Sep 13 10:50:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 10:50:27 2004 Subject: [ python-Bugs-1027105 ] HardwareRandom should be renamed OSRandom Message-ID: Bugs item #1027105, was opened at 2004-09-13 01:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027105&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: HardwareRandom should be renamed OSRandom Initial Comment: The new random.HardwareRandom class is probably better called "OSRandom" . Calling it HardwareRandom might lead people to think it's using special randomness-generating hardware (which exists on some chips, for example). But in actuality it might be getting randomness from thread racing, OS data structures, network statistics, time-of-day, etc... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027105&group_id=5470 From noreply at sourceforge.net Mon Sep 13 13:17:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 13:17:24 2004 Subject: [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks Message-ID: Bugs item #756104, was opened at 2003-06-18 00:25 Message generated for change (Comment added) made by targeted You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alex R.M. Turner (plexq) Assigned to: Nobody/Anonymous (nobody) Summary: Calling socket.recv() with a large number breaks Initial Comment: I have a backup script that calls socket.recv() passing the amount of data that is left to get for a given file as the argument. For very large files (I have one here that is 1.9Gig) it seems to break horribly after receiving about 130Meg. I have tried to track it down precisely with basic debugging (putting in print statements in the python code) but it just seams to freak out around the 130meg mark, and it just doesn't make sense. If I change the argument passed to recv to 32767 it works just fine. I have attatched the loop that reads data from the socket (In a working state, the bad code is commented out). ---------------------------------------------------------------------- Comment By: Dmitry Dvoinikov (targeted) Date: 2004-09-13 17:17 Message: Logged In: YES user_id=1120792 I've also been hit by this problem, not at a 130Meg read, but at a mere 10Meg. Because of that I had to change my code to read many small chunks rather than a single blob and that fixed it. Still, I disagree with tim_one. If recv() is limited with the amount of data it can read per call, it should be set and documented, otherwise it is a bug and the call is unreliable. Nobody has to follow the decribed "best-practice" of reading small chunks, it actually worsens code quality, and what's worse - it makes other stuff break. Example - I was using the SimpleXMLRPCServer (Lib/SimpleXMLRPCServer.py), and it contains the following line at it's heart: data = self.rfile.read(int(self.headers["content-length"])) Guess what was happening with requests with content-length larger than 10Meg (in my case). I've aso thought the problem was with max() instead of min(), but as tim_one rightfully pointed out, this was a desired behaviour. Ironically though, replacing max() with min() fixes the problem as there is no more huge reads at lower level. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-27 06:41 Message: Logged In: YES user_id=31435 potterru, I don't believe plexq was using _fileobject.read() -- he said he was using socket.recv(), and all the comments later were consistent with that. The code you found does appear to *intend* max(): code following the snippet you quoted clearly expects that it may have read more than "left" bytes, and it would not be worrying about that had min() been intended. I agree the code is pretty inscrutable regardless, but we'd have to ask Guido why he wrote it that way. In any case, since this bug report is about socket.recv(), if you want to make a case that _fileobject.read() is buggy you should open a new report for that. ---------------------------------------------------------------------- Comment By: Igor E. Poteryaev (potterru) Date: 2004-07-26 17:23 Message: Logged In: YES user_id=48596 It looks like bug in module socket.py in _fileobject.read method. ... while True:     left = size - buf_len     recv_size = max(self._rbufsize, left)     data = self._sock.recv(recv_size) This code should read not more than *left* or *buffer size* So, it should be min instead of max ! Should I file a bug/patch for this ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-19 00:51 Message: Logged In: YES user_id=31435 I assume you're running on Linux. Python's implementation of recv asks the platform malloc for a buffer of the size requested, and raises an exception if malloc returns NULL. Unfortunately, malloc on Linux has a nasty habit of returning non-NULL even if there's no chance you can actually use the amount of memory requested. There's really nothing Python can do about that. So back to Jeremy's comment: try the same thing in C. If you get ridiculous behavior there too, it's a platform C/OS bug, and Python won't be able to hide it from you. ---------------------------------------------------------------------- Comment By: Alex R.M. Turner (plexq) Date: 2003-06-19 00:22 Message: Logged In: YES user_id=60034 That as maybe - it might be worth putting a suggested maximum in the docs. However I would say that given that an IPv6 packet could be as large as 2Gig, it's not unreasonable to ask for a packet as large as 1 Gig. Wether the problem is in glibc or python I don't know, although it seems that asking for a buffer of 1.3 Gig in size, and passing that to recv() would be odd behaviour on a current system in C given that most systems couldn't allocate that much memory to a buffer ;). I have written fairly extensive socket code in C/C++ before, and I never used anything larger than 65536 for the obvious reason that you can't receive anything bigger than that in IPv4 (and most NICs can't handle anything that big either). I figured it would be interesting to see what happened :). I have a penchant for being the only person in history to do quite a few things apparently! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 22:29 Message: Logged In: YES user_id=31435 BTW, if you're new to socket programming, do read Python's socket programming HOWTO: http://www.amk.ca/python/howto/sockets/ I expect you're the only person in history to try passing such a large value to recv() -- even if it worked, you'd almost certainly run out of memory trying to allocate buffer space for 1.9GB. sockets are a low-level facility, and it's common to pass a relatively small power of 2 (for best match with hardware and network realities). ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-18 22:02 Message: Logged In: YES user_id=31392 What happens when you write a C program that does the same thing? I expect you'll see similar problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 From noreply at sourceforge.net Mon Sep 13 14:38:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 14:38:20 2004 Subject: [ python-Bugs-1027206 ] unicode DNS names in socket, urllib, urlopen Message-ID: Bugs item #1027206, was opened at 2004-09-13 14:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027206&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Damjan Georgievski (gdamjan) Assigned to: Nobody/Anonymous (nobody) Summary: unicode DNS names in socket, urllib, urlopen Initial Comment: http://docs.python.org/whatsnew/node18.html says that unicode host names are allowed in the socket module (automatically converting them by the IDNA spec), but is seems the support is not fully implemented. only the connect method of a socket instance will do the auto conversion to a 'idna' string. socket.getaddr* functions will not! Also other modules should support unicode hostnames. (httplib already does) but urllib and urllib2 don't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027206&group_id=5470 From noreply at sourceforge.net Mon Sep 13 16:11:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 16:11:21 2004 Subject: [ python-Bugs-756104 ] Calling socket.recv() with a large number breaks Message-ID: Bugs item #756104, was opened at 2003-06-17 14:25 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alex R.M. Turner (plexq) Assigned to: Nobody/Anonymous (nobody) Summary: Calling socket.recv() with a large number breaks Initial Comment: I have a backup script that calls socket.recv() passing the amount of data that is left to get for a given file as the argument. For very large files (I have one here that is 1.9Gig) it seems to break horribly after receiving about 130Meg. I have tried to track it down precisely with basic debugging (putting in print statements in the python code) but it just seams to freak out around the 130meg mark, and it just doesn't make sense. If I change the argument passed to recv to 32767 it works just fine. I have attatched the loop that reads data from the socket (In a working state, the bad code is commented out). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-13 10:11 Message: Logged In: YES user_id=31435 As Jeremy implied at the start, someone needs to demonstrate that "the bug" is actually in Python, not in your platform's implementation of sockets. If a C program displays the same behavior, your complaint is with your platform socket implementation. Sockets are low-level gimmicks, which is why Jeremy expected a C program to fail the same way. ---------------------------------------------------------------------- Comment By: Dmitry Dvoinikov (targeted) Date: 2004-09-13 07:17 Message: Logged In: YES user_id=1120792 I've also been hit by this problem, not at a 130Meg read, but at a mere 10Meg. Because of that I had to change my code to read many small chunks rather than a single blob and that fixed it. Still, I disagree with tim_one. If recv() is limited with the amount of data it can read per call, it should be set and documented, otherwise it is a bug and the call is unreliable. Nobody has to follow the decribed "best-practice" of reading small chunks, it actually worsens code quality, and what's worse - it makes other stuff break. Example - I was using the SimpleXMLRPCServer (Lib/SimpleXMLRPCServer.py), and it contains the following line at it's heart: data = self.rfile.read(int(self.headers["content-length"])) Guess what was happening with requests with content-length larger than 10Meg (in my case). I've aso thought the problem was with max() instead of min(), but as tim_one rightfully pointed out, this was a desired behaviour. Ironically though, replacing max() with min() fixes the problem as there is no more huge reads at lower level. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 20:41 Message: Logged In: YES user_id=31435 potterru, I don't believe plexq was using _fileobject.read() -- he said he was using socket.recv(), and all the comments later were consistent with that. The code you found does appear to *intend* max(): code following the snippet you quoted clearly expects that it may have read more than "left" bytes, and it would not be worrying about that had min() been intended. I agree the code is pretty inscrutable regardless, but we'd have to ask Guido why he wrote it that way. In any case, since this bug report is about socket.recv(), if you want to make a case that _fileobject.read() is buggy you should open a new report for that. ---------------------------------------------------------------------- Comment By: Igor E. Poteryaev (potterru) Date: 2004-07-26 07:23 Message: Logged In: YES user_id=48596 It looks like bug in module socket.py in _fileobject.read method. ... while True:     left = size - buf_len     recv_size = max(self._rbufsize, left)     data = self._sock.recv(recv_size) This code should read not more than *left* or *buffer size* So, it should be min instead of max ! Should I file a bug/patch for this ? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 14:51 Message: Logged In: YES user_id=31435 I assume you're running on Linux. Python's implementation of recv asks the platform malloc for a buffer of the size requested, and raises an exception if malloc returns NULL. Unfortunately, malloc on Linux has a nasty habit of returning non-NULL even if there's no chance you can actually use the amount of memory requested. There's really nothing Python can do about that. So back to Jeremy's comment: try the same thing in C. If you get ridiculous behavior there too, it's a platform C/OS bug, and Python won't be able to hide it from you. ---------------------------------------------------------------------- Comment By: Alex R.M. Turner (plexq) Date: 2003-06-18 14:22 Message: Logged In: YES user_id=60034 That as maybe - it might be worth putting a suggested maximum in the docs. However I would say that given that an IPv6 packet could be as large as 2Gig, it's not unreasonable to ask for a packet as large as 1 Gig. Wether the problem is in glibc or python I don't know, although it seems that asking for a buffer of 1.3 Gig in size, and passing that to recv() would be odd behaviour on a current system in C given that most systems couldn't allocate that much memory to a buffer ;). I have written fairly extensive socket code in C/C++ before, and I never used anything larger than 65536 for the obvious reason that you can't receive anything bigger than that in IPv4 (and most NICs can't handle anything that big either). I figured it would be interesting to see what happened :). I have a penchant for being the only person in history to do quite a few things apparently! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-18 12:29 Message: Logged In: YES user_id=31435 BTW, if you're new to socket programming, do read Python's socket programming HOWTO: http://www.amk.ca/python/howto/sockets/ I expect you're the only person in history to try passing such a large value to recv() -- even if it worked, you'd almost certainly run out of memory trying to allocate buffer space for 1.9GB. sockets are a low-level facility, and it's common to pass a relatively small power of 2 (for best match with hardware and network realities). ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-18 12:02 Message: Logged In: YES user_id=31392 What happens when you write a C program that does the same thing? I expect you'll see similar problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470 From noreply at sourceforge.net Mon Sep 13 18:36:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 18:36:36 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 10:30 Message generated for change (Comment added) made by cdgregorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- >Comment By: Gregor Richards (cdgregorr) Date: 2004-09-13 09:36 Message: Logged In: YES user_id=835341 I managed to track down the problem. Both of these architectures require a cc flag to build in 64-bit mode, but the tests in configure were done without CFLAGS. Thus, they build 32-bit, and the wrong values came out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-07 10:57 Message: Logged In: YES user_id=31435 What are LONG_BIT and SIZEOF_LONG on these platforms? It doesn't matter whether gcc is being used, if LONG_BIT is defined incorrectly for the platform, then it's defined incorrectly period. Read the comment you quoted to see why it doesn't matter whether Python "compiles fine" if you disable this. It's guarding against runtime errors in Python's intobject.c, which needs a correct value for LONG_BIT. Presumably LONG_BIT should be 64 on these boxes, and SIZEOF_LONG should be 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Mon Sep 13 19:45:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 19:45:43 2004 Subject: [ python-Bugs-1027394 ] socket.ssl should explain that it is a 2/3 connection Message-ID: Bugs item #1027394, was opened at 2004-09-13 12:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027394&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: socket.ssl should explain that it is a 2/3 connection Initial Comment: When you try to connect via socket.ssl(), python attempts a ssl2 connection then negotiates up. On some servers however ssl2 is disabled making the connection fail. The documentation should mention this limitation. If you want to connect to an ssl3 or tls1 only server, you need to modify the ssl context this method uses. I submitted a patch (889813) some time ago to allow the context to be specified as an optional argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027394&group_id=5470 From noreply at sourceforge.net Mon Sep 13 19:50:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 19:51:26 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2004-09-13 17:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 10:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 17:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 16:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 10:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 19:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 17:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 05:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 17:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 16:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 16:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 20:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 20:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 19:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 17:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 06:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 18:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 10:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 05:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 17:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 16:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 16:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 08:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 16:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 16:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 18:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 18:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 15:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 17:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 03:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 19:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 10:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 02:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 18:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 11:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 12:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 07:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 18:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 00:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 14:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 06:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Mon Sep 13 22:00:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 22:00:49 2004 Subject: [ python-Bugs-1026480 ] iso-latin-1 strings and functions lower & upper Message-ID: Bugs item #1026480, was opened at 2004-09-11 21:28 Message generated for change (Comment added) made by scott_daniels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026480&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: iso-latin-1 strings and functions lower & upper Initial Comment: I have no problems in Python in using strings which contain accented letters (my Emacs has no problems in producing them using one-byte iso-8859-1 encoding). However functions 'lower' and 'upper' do not work properly on these letters as shown below (I hope all accents appear properly within your browsers): ------------------------------------------------------------- as = "a?????" # except for the first 'a', all other have accents AS = "A?????" # except for the first 'A', all other have accents print "direct: %s -- %s" % (as, AS) print "lower: %s -- %s" % (as.lower(), AS.lower()) print "upper: %s -- %s" % (as.upper(), AS.upper()) ------------------------------------------------------------- The output is: -------------------------------------------------------------- direct: a????? -- A????? lower: a????? -- a????? upper: A????? -- A????? -------------------------------------------------------------- i.e., accented letters (above 128) are not translated. It did not make any difference to put the line # -*- coding: iso-latin-1 -*- about the encoding as recommended by PEP 0263. I am not sure whether this is a bug or it is intentional, i.e. these functions work only for pure ASCII letters. However it is a major inconvenience for those who use any language which is not English but uses the Latin aplphabet :-(. There should be some mechanism to signal these functions which Latin variant (iso-8859-1, iso-8859-2, ...) is being used, so that they behave properly; eg, optional second argument? ---------------------------------------------------------------------- Comment By: Scott David Daniels (scott_daniels) Date: 2004-09-13 20:00 Message: Logged In: YES user_id=493818 Note: lower and upper are defined as for ASCII on strs, but works correctly for unicode. uas = u"a?????" # except first 'a', all have accents UAS = u"A?????" # except first 'A', all have accents print u"direct: %s -- %s" % (uas, UAS) print u"lower: %s -- %s" % (uas.lower(), UAS.lower()) print u"upper: %s -- %s" % (uas.upper(), UAS.upper()) What you are asking is pretty hopeless. With two modules loaded with differing encodings, whose idea of "how to uppercase an 8-bit character" should be used? What you might want to use is: def codedupper(coding, string): return string.decode(coding).upper().encode(coding) def codedlower(coding, string): return string.decode(coding).lower().encode(coding) or: def latinupper(string): return string.decode('latin-1').upper().encode('latin-1') def latinlower(string): return string.decode('latin-1').lower().encode('latin-1') Any of these functions is well-defined even with several modules of differing encodings loaded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026480&group_id=5470 From noreply at sourceforge.net Tue Sep 14 00:17:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 00:17:25 2004 Subject: [ python-Bugs-1027566 ] Argument missing from calltip for new-style class init Message-ID: Bugs item #1027566, was opened at 2004-09-13 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027566&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Loren Guthrie (lguthrie) Assigned to: Nobody/Anonymous (nobody) Summary: Argument missing from calltip for new-style class init Initial Comment: The calltip for __init__ on new-style classes doesn't show the arguments like it does for old-style classes. >>> import idlelib.CallTips >>> class OldClass: ... """Old-style class""" ... def __init__(self, x): ... self.x = x ... >>> idlelib.CallTips.get_arg_text(OldClass) '(x)\nOld-style class' >>> class NewClass(object): ... """New-style class""" ... def __init__(self, x): ... self.x = x ... >>> idlelib.CallTips.get_arg_text(NewClass) 'New-style class' Changing CallTips.py line 134 (in get_arg_text) from if type(ob)==types.ClassType: to if type(ob) in [types.ClassType, types.TypeType]: SEEMS to fix the problem, but I have no idea what side-effects this might have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027566&group_id=5470 From noreply at sourceforge.net Tue Sep 14 00:23:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 00:23:33 2004 Subject: [ python-Bugs-1027105 ] HardwareRandom should be renamed OSRandom Message-ID: Bugs item #1027105, was opened at 2004-09-13 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027105&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: HardwareRandom should be renamed OSRandom Initial Comment: The new random.HardwareRandom class is probably better called "OSRandom" . Calling it HardwareRandom might lead people to think it's using special randomness-generating hardware (which exists on some chips, for example). But in actuality it might be getting randomness from thread racing, OS data structures, network statistics, time-of-day, etc... ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-13 17:23 Message: Logged In: YES user_id=80475 Renamed to SystemRandom. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027105&group_id=5470 From noreply at sourceforge.net Tue Sep 14 00:26:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 00:26:29 2004 Subject: [ python-Bugs-1027570 ] os.stat errors when using shared drive on XP or NT Message-ID: Bugs item #1027570, was opened at 2004-09-13 17:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027570&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: zeke (zeke_matzke) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat errors when using shared drive on XP or NT Initial Comment: The problem is when a file is executed from a shared drive then no letter drive name exists. So the result returned by os.path.exists(os.getcwd()) does not return true. Problem exists for both Active State and Idle on windows for both XP and NT2000: The problem is with os.stat even though the file open seems to work ok. Notice other error for Active State Python. Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0.2 ==== No Subprocess ==== >>> import os >>> os.getcwd() '\\Tardis\QCOS' >>> os.path.exists(os.getcwd()) False >>> os.stat(os.getcwd()) Traceback (most recent call last): File "", line 1, in ? os.stat(os.getcwd()) OSError: [Errno 2] No such file or directory: '\\Tardis\QCOS' >>> PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mhammond@skippinet.com.au) - see 'Help/About PythonWin' for further copyright information. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\intpyapp.py", line 332, in OnFileRun scriptutils.RunScript(None, None, showDlg) File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 259, in RunScript path = win32ui.FullPath(path) win32ui: The file name is invalid win32ui: Error in Command Message handler for command ID 36864, Code 0 >>> import os >>> os.getcwd() '\\Tardis\QCOS' >>> os.path.exists(os.getcwd()) False >>> os.stat(os.getcwd()) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 2] No such file or directory: '\\Tardis\QCOS' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027570&group_id=5470 From noreply at sourceforge.net Tue Sep 14 02:12:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 02:13:05 2004 Subject: [ python-Bugs-1026480 ] iso-latin-1 strings and functions lower & upper Message-ID: Bugs item #1026480, was opened at 2004-09-11 18:28 Message generated for change (Comment added) made by kowaltowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026480&group_id=5470 Category: None Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: iso-latin-1 strings and functions lower & upper Initial Comment: I have no problems in Python in using strings which contain accented letters (my Emacs has no problems in producing them using one-byte iso-8859-1 encoding). However functions 'lower' and 'upper' do not work properly on these letters as shown below (I hope all accents appear properly within your browsers): ------------------------------------------------------------- as = "a?????" # except for the first 'a', all other have accents AS = "A?????" # except for the first 'A', all other have accents print "direct: %s -- %s" % (as, AS) print "lower: %s -- %s" % (as.lower(), AS.lower()) print "upper: %s -- %s" % (as.upper(), AS.upper()) ------------------------------------------------------------- The output is: -------------------------------------------------------------- direct: a????? -- A????? lower: a????? -- a????? upper: A????? -- A????? -------------------------------------------------------------- i.e., accented letters (above 128) are not translated. It did not make any difference to put the line # -*- coding: iso-latin-1 -*- about the encoding as recommended by PEP 0263. I am not sure whether this is a bug or it is intentional, i.e. these functions work only for pure ASCII letters. However it is a major inconvenience for those who use any language which is not English but uses the Latin aplphabet :-(. There should be some mechanism to signal these functions which Latin variant (iso-8859-1, iso-8859-2, ...) is being used, so that they behave properly; eg, optional second argument? ---------------------------------------------------------------------- >Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-09-13 21:12 Message: Logged In: YES user_id=185428 I guess you are right from conceptual point of view. It is just somewhat frustrating because almost every language which uses the Latin alphabet needs characters above 128 (is English the only exception?). On the other hand 'lower' and 'upper' work for Unicode (really utf-8) representation in which many alphabets do not even have the concept of lower and upper cases! Your suggestion about 'latinlower' and 'latinupper' is basically what I asked for, but about 10 times slower than direct 'lower' and 'upper' :-(. Thanks anyway -- I guess the matter may be closed. ---------------------------------------------------------------------- Comment By: Scott David Daniels (scott_daniels) Date: 2004-09-13 17:00 Message: Logged In: YES user_id=493818 Note: lower and upper are defined as for ASCII on strs, but works correctly for unicode. uas = u"a?????" # except first 'a', all have accents UAS = u"A?????" # except first 'A', all have accents print u"direct: %s -- %s" % (uas, UAS) print u"lower: %s -- %s" % (uas.lower(), UAS.lower()) print u"upper: %s -- %s" % (uas.upper(), UAS.upper()) What you are asking is pretty hopeless. With two modules loaded with differing encodings, whose idea of "how to uppercase an 8-bit character" should be used? What you might want to use is: def codedupper(coding, string): return string.decode(coding).upper().encode(coding) def codedlower(coding, string): return string.decode(coding).lower().encode(coding) or: def latinupper(string): return string.decode('latin-1').upper().encode('latin-1') def latinlower(string): return string.decode('latin-1').lower().encode('latin-1') Any of these functions is well-defined even with several modules of differing encodings loaded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026480&group_id=5470 From noreply at sourceforge.net Tue Sep 14 09:32:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 09:32:56 2004 Subject: [ python-Bugs-1027206 ] unicode DNS names in socket, urllib, urlopen Message-ID: Bugs item #1027206, was opened at 2004-09-13 14:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027206&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Damjan Georgievski (gdamjan) Assigned to: Nobody/Anonymous (nobody) Summary: unicode DNS names in socket, urllib, urlopen Initial Comment: http://docs.python.org/whatsnew/node18.html says that unicode host names are allowed in the socket module (automatically converting them by the IDNA spec), but is seems the support is not fully implemented. only the connect method of a socket instance will do the auto conversion to a 'idna' string. socket.getaddr* functions will not! Also other modules should support unicode hostnames. (httplib already does) but urllib and urllib2 don't. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 09:32 Message: Logged In: YES user_id=21627 Would you be interested in developing patches? For the socket module, the bug is clear, and probably straight-forward to fix. For urllib[2], issues are more difficult, as Python should eventually support IRIs. It appears that draft-duerst-iri-09 is going to become the RFC, so changes for urllib either need to take this into account, or be postponed after the RFC is published. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027206&group_id=5470 From noreply at sourceforge.net Tue Sep 14 09:52:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 09:52:58 2004 Subject: [ python-Bugs-1026038 ] "ASCII" in doc section "String literals" Message-ID: Bugs item #1026038, was opened at 2004-09-10 20:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026038&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "ASCII" in doc section "String literals" Initial Comment: Section '2.4.1 String literals' says that shortstringchar and longstringchar are ASCII characters. This is wrong, however, because non-ASCII characters are allowed as well. The documentation of \xhh and \ooo (in the same section) says that they represent ASCII characters. It seems to me that they actually represent ISO-8859-1 characters (which is important if these escape sequences occur in a unicode string literal). Is that the intended behavior, by the way? Shouldn't it rather depend on the -*- coding -*- of the source file? Maybe also add a reference to PEP 263? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 09:52 Message: Logged In: YES user_id=21627 Thanks for your report. Fixed in ref2.tex 1.55 ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-11 17:08 Message: Logged In: YES user_id=1014490 > The documentation of \xhh and \ooo (in the same > section) says that they represent ASCII characters. It > seems to me that they actually represent ISO-8859-1 > characters (which is important if these escape > sequences occur in a unicode string literal). Correction: They represent bytes in normal strings and \u00xx in unicode strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1026038&group_id=5470 From noreply at sourceforge.net Tue Sep 14 09:55:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 09:55:19 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 19:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 09:55 Message: Logged In: YES user_id=21627 Did you specify CFLAGS during configure? If not, how did the flags get added for 64-bit mode? ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-13 18:36 Message: Logged In: YES user_id=835341 I managed to track down the problem. Both of these architectures require a cc flag to build in 64-bit mode, but the tests in configure were done without CFLAGS. Thus, they build 32-bit, and the wrong values came out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-07 19:57 Message: Logged In: YES user_id=31435 What are LONG_BIT and SIZEOF_LONG on these platforms? It doesn't matter whether gcc is being used, if LONG_BIT is defined incorrectly for the platform, then it's defined incorrectly period. Read the comment you quoted to see why it doesn't matter whether Python "compiles fine" if you disable this. It's guarding against runtime errors in Python's intobject.c, which needs a correct value for LONG_BIT. Presumably LONG_BIT should be 64 on these boxes, and SIZEOF_LONG should be 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Tue Sep 14 10:53:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 10:53:53 2004 Subject: [ python-Bugs-1027771 ] In DOM Node Objects, add more explanations for insertBefore Message-ID: Bugs item #1027771, was opened at 2004-09-14 10:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027771&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. DARCHE (madarche) Assigned to: Nobody/Anonymous (nobody) Summary: In DOM Node Objects, add more explanations for insertBefore Initial Comment: At http://www.python.org/doc/2.3.4/lib/dom-node-objects.html#l2h-4071 current documentation is: insertBefore(newChild, refChild) Insert a new child node before an existing child. It must be the case that refChild is a child of this node; if not, ValueError is raised. newChild is returned. While it could be more complete: insertBefore(newChild, refChild) Insert a new child node before an existing child. It must be the case that refChild is a child of this node; if not, ValueError is raised. newChild is returned. If refChild is None, it inserts newChild at the end of the list of children. Note that node.insertAfter(newKid, refChild), if it existed, would be precisely equivalent to node.insertBefore(newKid,refChild.getNextSibling()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027771&group_id=5470 From noreply at sourceforge.net Tue Sep 14 10:55:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 10:55:30 2004 Subject: [ python-Bugs-1027771 ] In DOM Node Objects, add more explanations for insertBefore Message-ID: Bugs item #1027771, was opened at 2004-09-14 10:53 Message generated for change (Settings changed) made by madarche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027771&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 2 Submitted By: M.-A. DARCHE (madarche) Assigned to: Nobody/Anonymous (nobody) Summary: In DOM Node Objects, add more explanations for insertBefore Initial Comment: At http://www.python.org/doc/2.3.4/lib/dom-node-objects.html#l2h-4071 current documentation is: insertBefore(newChild, refChild) Insert a new child node before an existing child. It must be the case that refChild is a child of this node; if not, ValueError is raised. newChild is returned. While it could be more complete: insertBefore(newChild, refChild) Insert a new child node before an existing child. It must be the case that refChild is a child of this node; if not, ValueError is raised. newChild is returned. If refChild is None, it inserts newChild at the end of the list of children. Note that node.insertAfter(newKid, refChild), if it existed, would be precisely equivalent to node.insertBefore(newKid,refChild.getNextSibling()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027771&group_id=5470 From noreply at sourceforge.net Tue Sep 14 20:05:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 20:05:40 2004 Subject: [ python-Bugs-909308 ] Embedded Python Interpreter in MFC apps leaks Message-ID: Bugs item #909308, was opened at 2004-03-03 13:24 Message generated for change (Comment added) made by rtrainor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909308&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David (yakumoklesk) Assigned to: Nobody/Anonymous (nobody) Summary: Embedded Python Interpreter in MFC apps leaks Initial Comment: I am embedding the python interpreter in my MFC multidocument application. In the mainframe class, at creation time, I do Py_Initialize(). When the program comes to an end, in the mainframe destructor, I do Py_Finalize(). No Pyobject is created, no PyRun_SimpleString is called, nothing but the Py_Initialize() and the Py_Finalize() only. But those simple calls make the program to report leaks, that when are breakpointed with _CrtSetBreakAlloc (using lib) the code "leaked" stops inside python code. I made a new project from scratch (multidocument also), without adding no line except Py_Initialize and Py_Finalize, an the leak already exists. I did a Dialog application and used the same calls, and the leak already exists. But when I make a non MFC application, the leak do not exists. Is this bug a real python bug, or its due an MFC bad implementation of memory allocation? Please, I need to know if there is a way to avoid this leaks, because I want to control what leaks are really mine (c++), what leaks are caused by c++ to python wrapped code, and what leaks are just python, to have a better control of the processes of my application. I am using Python 2.3.3 and VC++ 6.0 with service pack 5 on a Windows XP Professional with an Athlon XP. David. If any information is needed about the leaks and the lines that report to be leaked, just tell me and I'll made an inform. ---------------------------------------------------------------------- Comment By: Roland Trainor (rtrainor) Date: 2004-09-14 11:05 Message: Logged In: YES user_id=446714 I am seeing the same behavior. The leaks only appear when the VC++6.0 project is linking to one of the Multithreaded DLL runtime libraries - which occurs when you use MFC as a shared DLL. If the project is linking to one of the Multithreaded non-DLL runtime libraries - which occurs when you use MFC as a static library, the memory leaks do not appear. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909308&group_id=5470 From noreply at sourceforge.net Tue Sep 14 20:05:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 20:05:45 2004 Subject: [ python-Bugs-1028088 ] Cookies without values are silently ignored (by design?) Message-ID: Bugs item #1028088, was opened at 2004-09-14 13:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Sheppard (sirilyan) Assigned to: Nobody/Anonymous (nobody) Summary: Cookies without values are silently ignored (by design?) Initial Comment: Cookie._CookiePattern is the regular expression used to retrieve cookies from the HTTP_COOKIE environment variable. This pattern assumes that all cookies are in "name=value" format. A cookie that doesn't have an "=value" component is silently skipped over. (It's easy to generate a cookie like that - in JavaScript, document.cookie="broken" is all it takes.) >>> import Cookie >>> q = Cookie.SimpleCookie("pie=good; broken; other=thing") >>> q If ignoring cookies without a "=value" component is intended behaviour, it'd be nice to have a code comment warning that's what happens. If it's a bug, the cookie should be set with an empty value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470 From noreply at sourceforge.net Tue Sep 14 21:12:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 21:12:07 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 10:30 Message generated for change (Comment added) made by cdgregorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- >Comment By: Gregor Richards (cdgregorr) Date: 2004-09-14 12:12 Message: Logged In: YES user_id=835341 export CC="/usr/bin/gcc" export CFLAGS="-m64 -O2" ./configure - Gregor Richards ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 00:55 Message: Logged In: YES user_id=21627 Did you specify CFLAGS during configure? If not, how did the flags get added for 64-bit mode? ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-13 09:36 Message: Logged In: YES user_id=835341 I managed to track down the problem. Both of these architectures require a cc flag to build in 64-bit mode, but the tests in configure were done without CFLAGS. Thus, they build 32-bit, and the wrong values came out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-07 10:57 Message: Logged In: YES user_id=31435 What are LONG_BIT and SIZEOF_LONG on these platforms? It doesn't matter whether gcc is being used, if LONG_BIT is defined incorrectly for the platform, then it's defined incorrectly period. Read the comment you quoted to see why it doesn't matter whether Python "compiles fine" if you disable this. It's guarding against runtime errors in Python's intobject.c, which needs a correct value for LONG_BIT. Presumably LONG_BIT should be 64 on these boxes, and SIZEOF_LONG should be 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Tue Sep 14 21:14:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 21:14:38 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 10:30 Message generated for change (Comment added) made by cdgregorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- >Comment By: Gregor Richards (cdgregorr) Date: 2004-09-14 12:14 Message: Logged In: YES user_id=835341 By the way, I ended up making it work with ... export CC="$CC $CFLAGS" export CFLAGS= ./configure However, this should not be necessary. ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-14 12:12 Message: Logged In: YES user_id=835341 export CC="/usr/bin/gcc" export CFLAGS="-m64 -O2" ./configure - Gregor Richards ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 00:55 Message: Logged In: YES user_id=21627 Did you specify CFLAGS during configure? If not, how did the flags get added for 64-bit mode? ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-13 09:36 Message: Logged In: YES user_id=835341 I managed to track down the problem. Both of these architectures require a cc flag to build in 64-bit mode, but the tests in configure were done without CFLAGS. Thus, they build 32-bit, and the wrong values came out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-07 10:57 Message: Logged In: YES user_id=31435 What are LONG_BIT and SIZEOF_LONG on these platforms? It doesn't matter whether gcc is being used, if LONG_BIT is defined incorrectly for the platform, then it's defined incorrectly period. Read the comment you quoted to see why it doesn't matter whether Python "compiles fine" if you disable this. It's guarding against runtime errors in Python's intobject.c, which needs a correct value for LONG_BIT. Presumably LONG_BIT should be 64 on these boxes, and SIZEOF_LONG should be 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Wed Sep 15 04:00:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 04:00:16 2004 Subject: [ python-Bugs-1028306 ] date-datetime comparison Message-ID: Bugs item #1028306, was opened at 2004-09-14 21:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028306&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donnal Walter (donnal) Assigned to: Nobody/Anonymous (nobody) Summary: date-datetime comparison Initial Comment: > I was surprised to discover that > > >>> import datetime > >>> x = datetime.date(2004, 9, 14) > >>> y = datetime.datetime(2004, 9, 14, 6, 43, 15) > >>> print x == y > True > > How can these two objects be considered equal? They should not be. Please open a bug report. The problem is due to that datetime.datetime is a subclass of datetime.date: >>> isinstance(y, datetime.date) True >>> and date's comparison implementation believes that instances of date subclasses can be compared as if they *were* dates. Indeed, since a datetime.datetime is-a datetime.date, it's a bit hard to see why that shouldn't be allowed, and offhand I don't know of a principled way to fix this without breaking existing code that compares instances of user-defined subclasses of datetime.date to instances of datetime.date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028306&group_id=5470 From noreply at sourceforge.net Wed Sep 15 05:50:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 05:50:43 2004 Subject: [ python-Bugs-1028334 ] get_installer_filename Message-ID: Bugs item #1028334, was opened at 2004-09-15 11:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028334&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bingo (ww_dragon) Assigned to: Nobody/Anonymous (nobody) Summary: get_installer_filename Initial Comment: \Lib\distutils\command\bdist_wininst.py function get_installer_filename must return installer_name; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028334&group_id=5470 From noreply at sourceforge.net Wed Sep 15 11:05:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 11:05:28 2004 Subject: [ python-Bugs-1028447 ] Python 2.3.4 broken? Message-ID: Bugs item #1028447, was opened at 2004-09-15 09:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028447&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stan (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.4 broken? Initial Comment: Running python 2.3.4 with valgrind memory error detector gives A LOT of errors. They seem to be harmless but I think they'd better be fixed because you never know what happes in the future. Also: ALWAYS test development with valgrind! Attached is a script of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028447&group_id=5470 From noreply at sourceforge.net Wed Sep 15 15:32:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 15:32:39 2004 Subject: [ python-Bugs-1028447 ] Python 2.3.4 broken? Message-ID: Bugs item #1028447, was opened at 2004-09-15 10:05 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028447&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stan (sxanth) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.4 broken? Initial Comment: Running python 2.3.4 with valgrind memory error detector gives A LOT of errors. They seem to be harmless but I think they'd better be fixed because you never know what happes in the future. Also: ALWAYS test development with valgrind! Attached is a script of it. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-15 14:32 Message: Logged In: YES user_id=6656 Read Misc/README.valgrind in Python CVS, e.g. here: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/README.valgrind?rev=1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028447&group_id=5470 From noreply at sourceforge.net Wed Sep 15 19:02:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 19:02:27 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 21:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-15 18:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 19:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-12 04:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-11 00:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 23:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 23:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 23:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 22:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 20:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 20:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 01:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-07 00:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 23:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Wed Sep 15 19:03:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 19:04:01 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 21:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-15 18:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 18:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 19:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-12 04:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-11 00:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 23:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 23:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 23:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 22:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 20:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 20:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 01:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-07 00:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 23:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Wed Sep 15 19:28:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 19:28:57 2004 Subject: [ python-Bugs-1028697 ] Problem linking on windows using mingw32 and C++ Message-ID: Bugs item #1028697, was opened at 2004-09-15 13:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steve Menard (devilwolf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking on windows using mingw32 and C++ Initial Comment: When create a python extension in C++ and using ming32 to compile it, distutil will try to use 'cc' as the linker. The problem is that the CCompiler.link() method will substitude the linker it has found in linker_exe or linker_so with the first part of compiler_cxx. (lines 175-176) So adding the following line to Mingw32Compiler, near line 296 compiler_cxx='g++ -mno-cygwin -O -Wall', Fixes it for me. Quickly looking at the CygwinCompiler indicates it would suffer from he same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 From noreply at sourceforge.net Wed Sep 15 20:53:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 22:47:28 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 11:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 11:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 20:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 00:08:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 00:08:18 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 15:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 17:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 13:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 12:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 12:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 13:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 22:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 18:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 17:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 17:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 17:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 16:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 14:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 19:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 18:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 01:57:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 01:57:46 2004 Subject: [ python-Bugs-1028306 ] date-datetime comparison Message-ID: Bugs item #1028306, was opened at 2004-09-14 21:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028306&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donnal Walter (donnal) >Assigned to: Tim Peters (tim_one) Summary: date-datetime comparison Initial Comment: > I was surprised to discover that > > >>> import datetime > >>> x = datetime.date(2004, 9, 14) > >>> y = datetime.datetime(2004, 9, 14, 6, 43, 15) > >>> print x == y > True > > How can these two objects be considered equal? They should not be. Please open a bug report. The problem is due to that datetime.datetime is a subclass of datetime.date: >>> isinstance(y, datetime.date) True >>> and date's comparison implementation believes that instances of date subclasses can be compared as if they *were* dates. Indeed, since a datetime.datetime is-a datetime.date, it's a bit hard to see why that shouldn't be allowed, and offhand I don't know of a principled way to fix this without breaking existing code that compares instances of user-defined subclasses of datetime.date to instances of datetime.date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028306&group_id=5470 From noreply at sourceforge.net Thu Sep 16 02:02:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 02:02:38 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 04:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 19:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-12 23:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 09:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 08:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 11:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 06:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 02:17:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 02:17:10 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 17:17 Message: Logged In: YES user_id=341410 Raymond, from your first post on this topic, it seems as though you were previously implementing this functionality in binascii for some particular reason, and it seems as though it is to be included with binascii in the future, regardless of the outcome of this particular feature request. The only reason the binascii solution is better than status quo, is because a user doesn't need to implement arbitrarily large integer packing and unpacking themselves. On the other hand, it still requires the user make manual binascii.str_to_long(str_obj) calls in the case of it being part of a struct, so doesn't gain significantly. Now, one of the reasons why I requested a format code addition was because one can (un)pack multiple data types simultaneously with a single function call via struct. In nearly all of the use cases I have for packing and unpacking large integers, they are a part of other structures. In the cases where I have been packing and unpacking single integers, floats, etc., I still use struct because it is has nearly all of the functionality I need (signed, unsigned, big endian, little endian, char, short, long, long long, etc., lacking only arbitrarily large integer packing and unpacking). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 15:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 11:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 11:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 20:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 02:26:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 02:27:00 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 15:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 19:26 Message: Logged In: YES user_id=80475 I agree with Michael and Martin that variable length types do not belong in struct. The module is about working with fixed record layouts. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 19:17 Message: Logged In: YES user_id=341410 Raymond, from your first post on this topic, it seems as though you were previously implementing this functionality in binascii for some particular reason, and it seems as though it is to be included with binascii in the future, regardless of the outcome of this particular feature request. The only reason the binascii solution is better than status quo, is because a user doesn't need to implement arbitrarily large integer packing and unpacking themselves. On the other hand, it still requires the user make manual binascii.str_to_long(str_obj) calls in the case of it being part of a struct, so doesn't gain significantly. Now, one of the reasons why I requested a format code addition was because one can (un)pack multiple data types simultaneously with a single function call via struct. In nearly all of the use cases I have for packing and unpacking large integers, they are a part of other structures. In the cases where I have been packing and unpacking single integers, floats, etc., I still use struct because it is has nearly all of the functionality I need (signed, unsigned, big endian, little endian, char, short, long, long long, etc., lacking only arbitrarily large integer packing and unpacking). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 17:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 13:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 12:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 12:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 13:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 22:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 18:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 17:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 17:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 17:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 16:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 14:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 19:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 18:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 03:32:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 03:32:41 2004 Subject: [ python-Bugs-1028306 ] date-datetime comparison Message-ID: Bugs item #1028306, was opened at 2004-09-14 22:00 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028306&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Donnal Walter (donnal) Assigned to: Tim Peters (tim_one) Summary: date-datetime comparison Initial Comment: > I was surprised to discover that > > >>> import datetime > >>> x = datetime.date(2004, 9, 14) > >>> y = datetime.datetime(2004, 9, 14, 6, 43, 15) > >>> print x == y > True > > How can these two objects be considered equal? They should not be. Please open a bug report. The problem is due to that datetime.datetime is a subclass of datetime.date: >>> isinstance(y, datetime.date) True >>> and date's comparison implementation believes that instances of date subclasses can be compared as if they *were* dates. Indeed, since a datetime.datetime is-a datetime.date, it's a bit hard to see why that shouldn't be allowed, and offhand I don't know of a principled way to fix this without breaking existing code that compares instances of user-defined subclasses of datetime.date to instances of datetime.date. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-15 21:32 Message: Logged In: YES user_id=31435 Thanks for the report. Comparing a date to a datetime now acts like a mixed-type comparison; user-defined subclasses aren't affected; see NEWS for details. Lib/test/test_datetime.py 1.49 Misc/NEWS 1.1135 Modules/datetimemodule.c 1.75 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028306&group_id=5470 From noreply at sourceforge.net Thu Sep 16 04:31:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 04:31:43 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 19:31 Message: Logged In: YES user_id=341410 And as I stated, the 's' format character is also a "variable lengthed type". It just so happens that in most use cases I've had and observed for both the 's' format AND proposed 'g' format, the type size, is in fact, fixed at 'compile' time. It also happens that for the 'g' format, this fixed size is not in the set {1,2,4,8}, which are not limitations for the pre-existing 's' format. Please note that the only fundamental difference between the pre-existing 's' format and the proposed 'g' format, is that of a quick call to appropriate PyLong_* functions, and a range check as required by other integer types. Python is a tool. Struct is a tool. By changing the tool only slightly, we can add flexibility. The code is already there, minor glue would make it work, and would make it convenient for, I believe, more people than binascii. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 17:26 Message: Logged In: YES user_id=80475 I agree with Michael and Martin that variable length types do not belong in struct. The module is about working with fixed record layouts. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 17:17 Message: Logged In: YES user_id=341410 Raymond, from your first post on this topic, it seems as though you were previously implementing this functionality in binascii for some particular reason, and it seems as though it is to be included with binascii in the future, regardless of the outcome of this particular feature request. The only reason the binascii solution is better than status quo, is because a user doesn't need to implement arbitrarily large integer packing and unpacking themselves. On the other hand, it still requires the user make manual binascii.str_to_long(str_obj) calls in the case of it being part of a struct, so doesn't gain significantly. Now, one of the reasons why I requested a format code addition was because one can (un)pack multiple data types simultaneously with a single function call via struct. In nearly all of the use cases I have for packing and unpacking large integers, they are a part of other structures. In the cases where I have been packing and unpacking single integers, floats, etc., I still use struct because it is has nearly all of the functionality I need (signed, unsigned, big endian, little endian, char, short, long, long long, etc., lacking only arbitrarily large integer packing and unpacking). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 15:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 11:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 11:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 20:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 04:52:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 04:52:20 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 16:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-15 22:52 Message: Logged In: YES user_id=31435 Use cases are important. Oddly(?) enough, I've never had a need for a bigint conversion in a C struct, and have a hard time imagining I will someday. All the cases I've had (and I've had more than a few) were one-shot str->long or long->str conversions. An obvious example in the core is the tedious encode_long() and decode_long() functions in pickle.py. Note that a pickle.encode_long() workalike doesn't know in advance how many bytes it needs, which would make using struct a PITA for that particular use case. If a proposal isn't convenient for taking over existing conversions of this nature, that counts against it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 22:31 Message: Logged In: YES user_id=341410 And as I stated, the 's' format character is also a "variable lengthed type". It just so happens that in most use cases I've had and observed for both the 's' format AND proposed 'g' format, the type size, is in fact, fixed at 'compile' time. It also happens that for the 'g' format, this fixed size is not in the set {1,2,4,8}, which are not limitations for the pre-existing 's' format. Please note that the only fundamental difference between the pre-existing 's' format and the proposed 'g' format, is that of a quick call to appropriate PyLong_* functions, and a range check as required by other integer types. Python is a tool. Struct is a tool. By changing the tool only slightly, we can add flexibility. The code is already there, minor glue would make it work, and would make it convenient for, I believe, more people than binascii. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 20:26 Message: Logged In: YES user_id=80475 I agree with Michael and Martin that variable length types do not belong in struct. The module is about working with fixed record layouts. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 20:17 Message: Logged In: YES user_id=341410 Raymond, from your first post on this topic, it seems as though you were previously implementing this functionality in binascii for some particular reason, and it seems as though it is to be included with binascii in the future, regardless of the outcome of this particular feature request. The only reason the binascii solution is better than status quo, is because a user doesn't need to implement arbitrarily large integer packing and unpacking themselves. On the other hand, it still requires the user make manual binascii.str_to_long(str_obj) calls in the case of it being part of a struct, so doesn't gain significantly. Now, one of the reasons why I requested a format code addition was because one can (un)pack multiple data types simultaneously with a single function call via struct. In nearly all of the use cases I have for packing and unpacking large integers, they are a part of other structures. In the cases where I have been packing and unpacking single integers, floats, etc., I still use struct because it is has nearly all of the functionality I need (signed, unsigned, big endian, little endian, char, short, long, long long, etc., lacking only arbitrarily large integer packing and unpacking). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 18:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 14:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 13:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 13:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 14:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 23:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 19:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 18:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 18:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 18:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 17:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 15:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 20:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 19:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 18:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 10:07:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 10:07:56 2004 Subject: [ python-Bugs-1029047 ] No command line args when script run without python.exe Message-ID: Bugs item #1029047, was opened at 2004-09-16 12:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029047&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kerim Borchaev (warkid) Assigned to: Nobody/Anonymous (nobody) Summary: No command line args when script run without python.exe Initial Comment: In "FolderOptions/File types" for "py" files in action "open" "Application used to perform action" reads: "C:\Python24\python.exe" "%1" This results in such behaviour: ----------- D:\temp>copy con test.py import sys print sys.version print sys.argv[1] ^Z 1 file(s) copied. D:\temp>python.exe test.py hello 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] hello D:\temp>test.py hello 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] Traceback (most recent call last): File "D:\temp\test.py", line 3, in ? print sys.argv[1] IndexError: list index out of range ----------- Python2.3 had this string for "Application used...": "C:\Python24\python.exe" "%1" %* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029047&group_id=5470 From noreply at sourceforge.net Thu Sep 16 10:47:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 10:52:30 2004 Subject: [ python-Bugs-1029047 ] No command line args when script run without python.exe Message-ID: Bugs item #1029047, was opened at 2004-09-16 17:07 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029047&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kerim Borchaev (warkid) Assigned to: Nobody/Anonymous (nobody) Summary: No command line args when script run without python.exe Initial Comment: In "FolderOptions/File types" for "py" files in action "open" "Application used to perform action" reads: "C:\Python24\python.exe" "%1" This results in such behaviour: ----------- D:\temp>copy con test.py import sys print sys.version print sys.argv[1] ^Z 1 file(s) copied. D:\temp>python.exe test.py hello 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] hello D:\temp>test.py hello 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] Traceback (most recent call last): File "D:\temp\test.py", line 3, in ? print sys.argv[1] IndexError: list index out of range ----------- Python2.3 had this string for "Application used...": "C:\Python24\python.exe" "%1" %* ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-16 17:47 Message: Logged In: YES user_id=671362 This is a duplicate of bug #1022010 http://www.python.org/sf/1022010 Try a new installer from http://www.dcl.hpi.uni-potsdam.de/home/loewis/python- 2.4a3.3.msi P.S. Is the latest MSI installer uploaded to www.python.org? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029047&group_id=5470 From noreply at sourceforge.net Thu Sep 16 13:01:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 13:01:08 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-16 12:01 Message: Logged In: YES user_id=6656 I like it. I hope to be more specific than that soon :) Sorry for the delay... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 01:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-13 05:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 15:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 14:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 17:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 14:57:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 14:57:53 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 11:33 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-09-16 14:57 Message: Logged In: YES user_id=11105 ceval.diff: What happens when pvalue is not a string? And, isn't it required to call PyErr_NormalizeException() after the PyErr_Fetch? BTW: I'm currently working on a somewhat similar problem (augmenting an error message with more info) in a non-python core project. I'll take this code and upload a patch using this approach. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 13:01 Message: Logged In: YES user_id=6656 I like it. I hope to be more specific than that soon :) Sorry for the delay... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 02:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-13 06:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 16:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 16:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 18:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 13:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 15:49:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 15:49:33 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 11:33 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-09-16 15:49 Message: Logged In: YES user_id=11105 I don't have time to cook up a complete patch for ceval.c, but the attached extend_exception.c file contains a function which works for me, in another context. It could be used to raise a type error containing the original exception's text. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 14:57 Message: Logged In: YES user_id=11105 ceval.diff: What happens when pvalue is not a string? And, isn't it required to call PyErr_NormalizeException() after the PyErr_Fetch? BTW: I'm currently working on a somewhat similar problem (augmenting an error message with more info) in a non-python core project. I'll take this code and upload a patch using this approach. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 13:01 Message: Logged In: YES user_id=6656 I like it. I hope to be more specific than that soon :) Sorry for the delay... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 02:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-13 06:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 16:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 16:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 18:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 13:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 15:57:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 15:57:58 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-16 14:57 Message: Logged In: YES user_id=6656 Raymond's patch strikes me as a nicely simple approach. Thomas' strikes me as though it should be made into some general function which build_class should use. This is probably objectively the better solution, but risks opening a large can of worms... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 14:49 Message: Logged In: YES user_id=11105 I don't have time to cook up a complete patch for ceval.c, but the attached extend_exception.c file contains a function which works for me, in another context. It could be used to raise a type error containing the original exception's text. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 13:57 Message: Logged In: YES user_id=11105 ceval.diff: What happens when pvalue is not a string? And, isn't it required to call PyErr_NormalizeException() after the PyErr_Fetch? BTW: I'm currently working on a somewhat similar problem (augmenting an error message with more info) in a non-python core project. I'll take this code and upload a patch using this approach. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 12:01 Message: Logged In: YES user_id=6656 I like it. I hope to be more specific than that soon :) Sorry for the delay... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 01:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-13 05:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 15:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 14:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 17:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 16:14:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 16:14:24 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 11:33 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-09-16 16:14 Message: Logged In: YES user_id=11105 After reading Raymond's patch again - if it fixes the original problem, mwh's comment is probably right. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 15:57 Message: Logged In: YES user_id=6656 Raymond's patch strikes me as a nicely simple approach. Thomas' strikes me as though it should be made into some general function which build_class should use. This is probably objectively the better solution, but risks opening a large can of worms... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 15:49 Message: Logged In: YES user_id=11105 I don't have time to cook up a complete patch for ceval.c, but the attached extend_exception.c file contains a function which works for me, in another context. It could be used to raise a type error containing the original exception's text. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 14:57 Message: Logged In: YES user_id=11105 ceval.diff: What happens when pvalue is not a string? And, isn't it required to call PyErr_NormalizeException() after the PyErr_Fetch? BTW: I'm currently working on a somewhat similar problem (augmenting an error message with more info) in a non-python core project. I'll take this code and upload a patch using this approach. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 13:01 Message: Logged In: YES user_id=6656 I like it. I hope to be more specific than that soon :) Sorry for the delay... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 02:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-13 06:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 16:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 16:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 15:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 18:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 13:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 18:42:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 18:42:30 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 04:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 11:42 Message: Logged In: YES user_id=80475 Made minor adjustments to the patch (the PyErr_Clear() was not needed) and applied as Python/ceval.c 2.417. If someone comes up with a better solution, feel free to apply it. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 09:14 Message: Logged In: YES user_id=11105 After reading Raymond's patch again - if it fixes the original problem, mwh's comment is probably right. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 08:57 Message: Logged In: YES user_id=6656 Raymond's patch strikes me as a nicely simple approach. Thomas' strikes me as though it should be made into some general function which build_class should use. This is probably objectively the better solution, but risks opening a large can of worms... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 08:49 Message: Logged In: YES user_id=11105 I don't have time to cook up a complete patch for ceval.c, but the attached extend_exception.c file contains a function which works for me, in another context. It could be used to raise a type error containing the original exception's text. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-09-16 07:57 Message: Logged In: YES user_id=11105 ceval.diff: What happens when pvalue is not a string? And, isn't it required to call PyErr_NormalizeException() after the PyErr_Fetch? BTW: I'm currently working on a somewhat similar problem (augmenting an error message with more info) in a non-python core project. I'll take this code and upload a patch using this approach. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-16 06:01 Message: Logged In: YES user_id=6656 I like it. I hope to be more specific than that soon :) Sorry for the delay... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 19:02 Message: Logged In: YES user_id=80475 Michael, Thomas, any thoughts on the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-12 23:18 Message: Logged In: YES user_id=80475 The attached patch implements an augmented error message that preserves the traceback and detailed message while providing a hint about the high level routine that called it. Here's a sample run: >>> class T(bool): pass Traceback (most recent call last): File "", line 1, in -toplevel- class T(bool): TypeError: Error when calling the metaclass bases type 'bool' is not an acceptable base type ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 09:37 Message: Logged In: YES user_id=6656 Unfortunately, I think > Grab the text from the > underlying TypeError and append it to the higher level > message before re-raising TypeError. might be a bit of a bear to implement. If I'm being dumb about this, feel free to apply the cluestick (bearing in mind that in general stringifying the TypeError may execute Python code). There probably is no ideal solution to this -- it's a knotty problem. The problem with current CVS is that it can lose information, whereas before it failed to add it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:22 Message: Logged In: YES user_id=80475 If you want the best of all worlds. Grab the text from the underlying TypeError and append it to the higher level message before re-raising TypeError. I'm happy with whatever you decide to do. When deciding, be sure to consider bug #963956 -- it is a small disaster with the msg appearing totally unrelated to what caused it. And, no, the statement wasn't equivocal. Low level routines cannot know for all time and all situtations the context in which they were called. Sometimes they are fortunate and tend to be called by only one thing or in just one context; however, that is subject to change as soon as new high level routine decides to use that building block. In this particular case, the metaclass function call can launch just about anything. The callee really has no way of knowing the circumstances of how it was called -- in this case, one of the implicit actions of metaclasses. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 08:55 Message: Logged In: YES user_id=6656 > The core issue is that the lower level routines don't know > enough to create an informative error message That needs to be at least somewhat equivocal: sometimes they do... Isn't the attached sufficient? It makes the word 'module' appear in the error message you get when you try to subclass a module, at least. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 11:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 06:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Thu Sep 16 20:11:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 20:11:41 2004 Subject: [ python-Feature Requests-1023290 ] proposed struct module format code addition Message-ID: Feature Requests item #1023290, was opened at 2004-09-06 13:42 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: proposed struct module format code addition Initial Comment: I believe there should be a mechanism to load and unload arbitrarily large integers via the struct module. Currently, one would likely start with the 'Q' format character, creating the integer in a block-wise fashion with multiplies and shifts. This is OK, though it tends to lend itself to certain kinds of bugs. There is currently another method for getting large integers from strings and going back without the struct module: long(stri.encode('hex'), 16) hex(inte)[2:].decode('hex') Arguably, such things shouldn't be done for the packing and unpacking of binary data in general (the string slicing especially). I propose a new format character for the struct module, specifically because the struct module is to "Interpret strings as packed binary data". Perhaps 'g' and 'G' (eg. biGint) is sufficient, though any reasonable character should suffice. Endianness should be handled, and the number of bytes representing the object would be the same as with the 's' formatting code. That is, '>60G' would be an unsigned big-endian integer represented by 60 bytes (null filled if the magnitude of the passed integer is not large enough). The only reason why one wouldn't want this functionality in the struct module is "This module performs conversions between Python values and C structs represented as Python strings." and arbitrarily large integers are not traditionally part of a C struct (though I am sure many of us have implemented arbitrary precision integers with structs). The reason "not a C type" has been used to quash the 'bit' and 'nibble' format character, because "masks and shifts" are able to emulate them, and though "masks and shifts" could also be used here, I have heard myself and others state that there should be an easy method for converting between large longs and strings. A side-effect for allowing arbitrarily large integers to be represented in this fashion is that its functionality could, if desired, subsume the other integer type characters, as well as fill in the gaps for nonstandard size integers (3, 5, 6, 7 etc. byte integers), that I (and I am sure others) have used in various applications. Currently no implementation exists, and I don't have time to do one now. Having taken a look at longobject.c and structmodule.c, I would likely be able to make a patch to the documentation, structmodule.c, and test_struct.py around mid October, if this functionality is desireable to others and accepted. While I doubt that a PEP for this is required, if necessary I would write one up with a sample implementation around mid October. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-16 11:11 Message: Logged In: YES user_id=341410 Curse you Tim, for your core Python experience *wink*. Pickle is one example where a pascal-like encoding of longs was an encoding decision made to be flexible and space efficient. Certainly we have disparate use cases. Mine is for fixed struct-like records with multiple types. With pickle, any /thought/ of fixed records are tossed out the window with variable-lengthed types like strings, longs, lists, tuples and dicts, and I believe aren't really comparable. Now, variable-lengthed longs packed in little-endian format already have a mechanism for encoding and decoding via pickle.en/decode_long (though it is wholly undocumented), and seemingly is going to get another in binascii. Fixed-lengthed, optional signed/unsigned, optional little-endian/big-endian longs do not have a mechanism for encoding and decoding, which is what I am asking for. I will point out that 128 bit integers are gaining support on newer 32 and 64 bit processors and C compilers for them (SSE on x86, Itanium, etc.). In the future, a new code for these 128 bit integers may be asked for inclusion. With a variable-width integer type, all future "hey, we now have x-byte types in C, where is struct support in Python?", can be answered with the proposed, "choose your integer size" format code. That is to say, this format code is future proof, unless integer types start wandering from integer byte widths. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-15 19:52 Message: Logged In: YES user_id=31435 Use cases are important. Oddly(?) enough, I've never had a need for a bigint conversion in a C struct, and have a hard time imagining I will someday. All the cases I've had (and I've had more than a few) were one-shot str->long or long->str conversions. An obvious example in the core is the tedious encode_long() and decode_long() functions in pickle.py. Note that a pickle.encode_long() workalike doesn't know in advance how many bytes it needs, which would make using struct a PITA for that particular use case. If a proposal isn't convenient for taking over existing conversions of this nature, that counts against it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 19:31 Message: Logged In: YES user_id=341410 And as I stated, the 's' format character is also a "variable lengthed type". It just so happens that in most use cases I've had and observed for both the 's' format AND proposed 'g' format, the type size, is in fact, fixed at 'compile' time. It also happens that for the 'g' format, this fixed size is not in the set {1,2,4,8}, which are not limitations for the pre-existing 's' format. Please note that the only fundamental difference between the pre-existing 's' format and the proposed 'g' format, is that of a quick call to appropriate PyLong_* functions, and a range check as required by other integer types. Python is a tool. Struct is a tool. By changing the tool only slightly, we can add flexibility. The code is already there, minor glue would make it work, and would make it convenient for, I believe, more people than binascii. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 17:26 Message: Logged In: YES user_id=80475 I agree with Michael and Martin that variable length types do not belong in struct. The module is about working with fixed record layouts. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 17:17 Message: Logged In: YES user_id=341410 Raymond, from your first post on this topic, it seems as though you were previously implementing this functionality in binascii for some particular reason, and it seems as though it is to be included with binascii in the future, regardless of the outcome of this particular feature request. The only reason the binascii solution is better than status quo, is because a user doesn't need to implement arbitrarily large integer packing and unpacking themselves. On the other hand, it still requires the user make manual binascii.str_to_long(str_obj) calls in the case of it being part of a struct, so doesn't gain significantly. Now, one of the reasons why I requested a format code addition was because one can (un)pack multiple data types simultaneously with a single function call via struct. In nearly all of the use cases I have for packing and unpacking large integers, they are a part of other structures. In the cases where I have been packing and unpacking single integers, floats, etc., I still use struct because it is has nearly all of the functionality I need (signed, unsigned, big endian, little endian, char, short, long, long long, etc., lacking only arbitrarily large integer packing and unpacking). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-15 15:08 Message: Logged In: YES user_id=80475 My vote is for binascii functions to parallel hexlify and unhexlify. Ideally, it would give the same result as long(hexlify(s), 16). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 11:53 Message: Logged In: YES user_id=341410 As you state, it already supports packing and unpacking a variable-lengthed type: strings. In the use cases I've had and seen for (un)packing strings with struct, it is the most common to define a static format code, and use that all the time. That is, you see things like ">HLLHB25s", that become string constants in a module. On the _very rare_ occasion where people want more flexibility in their types, I have seen both the use of fixed and variable pascal strings... def packit(arg1, arg2, arg3, strng): return struct.pack(">LHH%ip"%len(strng), arg1, arg2, arg3, strng) I would not expect any pascal-string-like packing of a large integer, though it is possible. I do expect that most people have similar use cases as I, and would pre-define their struct formatting code. In the case of other similar requests (long to string, string to long via a base256 representation, etc.) for use in cryptography, I expect that the regularity of structures used in cryptography would almost certainly result in formatting codes being module constants. To sum up, both in the case for the 's' and 'p' format codes, and the proposed 'g'/'G' formatting codes, the vast majority of use cases pre-define the length of the string and large integer on a per-structure basis via "25s", "25p", or "25g". Rarely are the lengths truely variable in the case of "%ip"%len(strng). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:03 Message: Logged In: YES user_id=6656 Oops, I see you actually address that (ish). But I still feel packing what is an essentially variable length type using the struct module is a bit strange. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 10:02 Message: Logged In: YES user_id=6656 Josiah, what do you suggest struct.calcsize does with the format code your proposing? I think this question encapsulates why I find this feature request a bit misdirected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-12 11:55 Message: Logged In: YES user_id=341410 Hexlify and unhexlify make sense for translating strings. Nowhere in the binascii module is there any mention of translating anything to/from integers, longs or floats. The only reason (un)hexlify make any sense at all is because we can get integers from hexlified strings, and get strings from hexlified integers with relative ease. I guess the trick with struct, at least with me, is not that I use it because it translates to/from C types, it is because it translates to/from types that I find useful. Its intersection with C types, as well as Python's intersection with C types, and my use intersection with the types is a convenient (but very engineered and understandable) coincidence. It would be another very convenient (but also engineered *wink*) coincidence if I didn't have to first extract a section of data, then translate it, in order to get one large integer. In the cases that I would truely find useful, big integers are a part of what would be called structs in the C world, and wouldn't require additional processing over what I'm already doing for other integers and floats. I was looking around, and it turns out that in 2001, Paul Rubin requested that one be able to translate to/from arbitrary bases via the C-level format function. In that discussion, Paul made the case that there should be a method to get arbitrarily long integers to and from strings: "The struct module doesn't give any way of converting arbitrary ints (meaning longs) to binary. Really, it's needed. Some people do it with gmpy, but if Python is going to support longs as a built-in type, one shouldn't have to resort to 3rd-party modules to read and write them in binary." Guido followed up with: "OK, I believe you. Can you submit a patch?" It seems like this was in reference to being able to use functions in binascii for converting to/from arbitrary packed binary integer types in base 256 (http://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470 if you are interested). That request seems to have died because Paul dropped the ball. Me, I would prefer struct to binascii, if only because the code for doing this is already waiting to be used in struct, and because you can pull multiple objects from a single packed binary string, rather than one object per call. This would seemingly also satisfy complaints of being able to translate to/from base 256 for arbitrarily large integers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 20:40 Message: Logged In: YES user_id=31435 binascii makes sense because that's where the hexlify and unhexlify functions live, which are small conceptual steps away from what's needed here. Methods on numbers make sense too, and only seem strange because so few are clearly visible now (although, e.g., there are lots of them already, like number.__abs__ and number.__add__). The struct module makes sense too, although it would be darned ugly to document a refusal to accept the new codes in "native" mode; and struct has a high learning curve; and struct obviously never intended to support types that aren't supplied directly by C compilers (the "Pascal string" code seems weird now, but not at the time). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-10 16:18 Message: Logged In: YES user_id=341410 (sorry it took me a few days to get back to you, I am on a contract deadline crunch...just taking a break now) The *HTTPServer heirarchy is interesting in its own right, but really, each piece in the heirarchy adds functionality. A similar thing can be said of asyncore and all the modules that derive from it (asynchat, *HTTPServer, *XMLRPCServer, smtpd, etc.). In this case, since the struct module is already in C and the functions are not subclassable, creating another module that parses strings and sends pieces off to struct for actual decoding seems like a waste of a module, especially when the change is so minor. Now, binascii is being used in such a fashion by uu and binhex, but that is because binascii is the data processing component, where uu and binhex make a 'pretty' interface. Struct doesn't need a pretty interface, it is already pretty. Though as I have said before, I think it could use this small addition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 15:53 Message: Logged In: YES user_id=21627 Since you were asking: it is quite common that modules refer to related functionality. For example, BaseHTTPServer refers to SimpleHTTPServer and CGIHTTPServer. One might expect that a HTTP server also supports files and does CGI - but not this one; go elsewhere. Likewise, module binascii refers to modules uu and binhex. The math documentation points out that it does not support complex numbers, and that cmath is needed. The audioop documentation gives the function echocancel in the documentation, instead of implementing it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:38 Message: Logged In: YES user_id=341410 Martin, I was typing as you submitted your most recent comment. I am honestly shocked that you would suggest that longs should gain a method for encoding themselves as binary strings. Such a thing would then suggest that standard ints and floats also gain such methods. It would also imply that since one can go to strings, one should equivalently be able to come from strings via equivalent methods. Goodness, int.tostring(width) and int.fromstring(str)? But what about endianness? Looks like a big can of worms to me. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-08 15:03 Message: Logged In: YES user_id=341410 Structures (aka C Structs) can contain arbitrarily large or small numbers of basic types inside them. As such, 'single long values' are still a valid use. I use struct for packing and unpacking of single items (8,4,2 byte integers, 1 byte integers are faster served via chr and ord) when necessary (because it is the most convenient), as well as a current contract where it is not uncommon to be packing and unpacking 256 byte structs. Those large structs contains various 1,2,4 and 8 byte integers, as well as a handful of 16 and 20 byte integers (which I must manually shift and mask during packing and unpacking). I'm a big boy, and can do it, but that doesn't mean that such functionality should be left out of Python. As for 'document the approach of going through hex inside the documentation of the struct module', I am curious about whether other modules do the same thing, that is to tell users "this functionality conceptually fits here X%, which is why it is documented here, but because it does not fit 100%, here is how you can do the same thing, which will likely look like a strange hack, require slicing potentially large strings, and be significantly slower than if we had just added the functionality, but here you go anyways." Now, I don't /need/ the feature, but I believe myself and others would find it useful. I also don't /require/ it be in struct, but no other modules offer equivalent functionality; Pickle and Marshal are Python-only, binascii (and bin2hex) are for converting between binary and ascii representations for transferring over non-8-bit channels (email, web, etc.), and no other module even comes close to offering a similar bit of "packs various types into a binary format, the same way C would" as struct. If anyone has a better place for it, I'm all ears (or eyes). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 14:45 Message: Logged In: YES user_id=21627 I would think that def long_as_bytes(lvalue, width): fmt = '%%.%dx' % (2*width) return unhexlify(fmt % (lvalue & ((1L<<8*width)-1))) is short enough for a recipe to not really make a C function necessary for that feature. However, if they are going to be provided somewhere, I would suggest that static methods on the long type might be the right place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:30 Message: Logged In: YES user_id=80475 The idea is to expose the _PyLong_FromByteArray() and _PyLong_AsByteArray() functions. While long(hexlify(b),16) is doable for bin2long, going the other way is not so simple. I agree that these are not struct related. Originally, I proposed the binascii module because one of the operations is so similar to hexlify(). As there other suggestions? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-08 12:15 Message: Logged In: YES user_id=21627 Apparently, the point of this request is that the method for converting long ints to binary should be "easily found in documentation". And also apparently, the submitter thinks that the struct module would be the place where people look. Now, that allows for a simple solution: document the approach of going through hex inside the documentation of the struct module. There is one other reason (beyond being primarily for C APIs) why such a feature should *not* be in the struct module: The struct module, most naturally, is about structures. However, I understand that the intended usage of this feature would not be structures, but single long values. Therefore, I consider it counter-intuitive to extend struct for that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 17:02 Message: Logged In: YES user_id=80475 Okay, submit a patch with docs and unittests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-06 16:44 Message: Logged In: YES user_id=341410 As I provide in the feature request, there is already a method for translating string <-> long. The problem with current methods for converting between large integers and strings is that they do not lend themselves to generally being understandable or to being documented. The struct module already provides two appropriate functions for handling packed binary data, a place for documenting functions involving packing and unpacking binary data, and whose implementation seems to be simple enough (one more format character, much of which borrowed from 's' character, and a call to _PyLong_FromByteArray seems to be sufficient). As for the binascii module, many of the functions listed seem like they should be wrapped into the encode/decode string methods, hexlify already being so in str.encode('hex'). To me, just being able to translate doesn't seem sufficient (we already can translate), but being able to do it well, have it documented well, and placed in a location that is obvious, fast and optimized for these kinds of things seems to be the right thing. >From what I can tell, the only reason why struct doesn't already have an equivalent format character to the proposed 'g' and 'G', is because the module was created to handle packed C structs and seemingly "nothing else". Considering there doesn't seem to be any other reasonable or easily documentable location for placing equivalent functionality (both packing and unpacking), I am of the opinion that restricting the packing and unpacking to C types in the struct module (when there are other useful types) is overkill. As I said, I will provide an implementation if desired. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 15:34 Message: Logged In: YES user_id=80475 FWIW, I'm working str/long conversion functions for the binascii module. Will that suit your needs? The tolong function is equivalent to: long(hexlify(b), 16) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 From noreply at sourceforge.net Thu Sep 16 22:35:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 22:35:41 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 15:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Thu Sep 16 22:36:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 22:37:01 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 15:35 Message generated for change (Settings changed) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) >Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Thu Sep 16 22:37:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 22:37:23 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 15:35 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- >Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:37 Message: Logged In: YES user_id=642545 Trying to upload the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Thu Sep 16 22:41:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 22:41:52 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 15:35 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- >Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:41 Message: Logged In: YES user_id=642545 Attached the patch with a better test case. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:37 Message: Logged In: YES user_id=642545 Trying to upload the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Thu Sep 16 22:45:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 22:45:06 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 15:35 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- >Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:45 Message: Logged In: YES user_id=642545 Okay, this one is actually the patch, not the test case itself. Sheesh. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:41 Message: Logged In: YES user_id=642545 Attached the patch with a better test case. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:37 Message: Logged In: YES user_id=642545 Trying to upload the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Thu Sep 16 23:00:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 23:00:48 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options <module 'spambayes.Options' from 'c:\spambayes\windows\py2exe\dist\lib\spambayes .zip\spambayes\Options.pyc'> >>> reload(Options) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 16:00 Message: Logged In: YES user_id=642545 Turns out there are two issues here: PEP 302 using the loader, and then the zip import caching the contents of zip files. At the suggestion of Phillip Eby, the PEP 302 stuff not using a loader has been put in a new bug that he is going to take care of: https://sourceforge.net/tracker/index.php?func=detail&aid=1029475&group_id=5470&atid=105470 So, now there is just the separate issue of the zip import not checking the file modification time. The attached patch makes sure when reload(aZipModule) is called that the file modification time is checked and that the contents are reloaded. More details are in my last comment. There is a test case that passes as well. The patch is at a more permanent location this time: http://www.chase3000.com/stephenh/patch-zipimport.txt ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 17:26 Message: Logged In: YES user_id=642545 Okay, so you talked me in to it. Besides the previous PyImport_ReloadModule patch, I modified zipimport.c to add another cache (zip_directory_cache of toc_entry's and zip_mtime_cache of modification times). On creation of a new ZipImporter or call to get_module_code, check_archive_mtime is called, which gets the new mtime and compares to the cached one. If they are different, it calls the old read_directory. read_directory was modified to, instead of creating a brand new path: [toc_entry] dictionary, clear and re-populate the same 'files' dictionary. This is so that if multiple ZipImporters are sharing an archive, and hence already sharing the same 'files' entry in zip_directory_cache, if one of them detects a new zip file and has the toc_entry's reloaded, the other ZipImporters will see the change to (as they all share the same dictionary). This was pretty much the same functionality before (sharing dictionaries), just that now read_directory clears/updates an exisitng one instead creating its own brand new one. Also, I had to add a sleep(1) call in testReload to ensure the modification time stamp would change. Again, either I don't have permissions to upload files, or I just can't figure it out, so the patch is at: http://sh5.beachead.com:8080/~stephen/patch.txt This is my first foray into Python coding, so double checking all of the reference counting inc/dec stuff would be a really good idea. I also took about 20 minutes to look at adding a reload test to test_importhooks.py, as suggested, but couldn't get it to work. I couldn't tell if it was because I was writing a flawed test (which is what I am suspecting) or if the PyImport_ReloadModule patch was not working. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 10:53 Message: Logged In: YES user_id=92689 Hm, I forgot about the caching of directory info. I don't think properly supporting reloading from zip files is worth the effort. It would be nice if it failed nicer, though. The reload patch is still cool, though, since it should fix reloading with PEP 302-style importers in general (yet zipimport may still choose not to support it). A reload test in test_importhooks.py would be a great addition. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 10:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 09:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 06:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 01:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Thu Sep 16 23:00:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 23:00:49 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 20:35 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2004-09-16 21:00 Message: Logged In: YES user_id=56214 Hi Stephen. I don't understand why 'path' has to be non-null. Not only that, but if it *is* null and the module has no __path__, your patch is still going to pass in a null path. So I'm confused. How did you discover the problem? Similarly, I'm confused as to why 'mod=reload(mod)' would be necessary now, but wasn't before. There have been no changes that I see in test_importhooks that would cause that. What was your testing methodology for this? ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 20:45 Message: Logged In: YES user_id=642545 Okay, this one is actually the patch, not the test case itself. Sheesh. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 20:41 Message: Logged In: YES user_id=642545 Attached the patch with a better test case. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 20:37 Message: Logged In: YES user_id=642545 Trying to upload the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Fri Sep 17 00:38:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 00:38:26 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 15:35 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- >Comment By: Stephen Haberman (filitov) Date: 2004-09-16 17:38 Message: Logged In: YES user_id=642545 You're right, the path = m.__path__ stuff was all wrong. I was not initializing path to NULL in the first place. I've attached the updated patch. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2004-09-16 16:00 Message: Logged In: YES user_id=56214 Hi Stephen. I don't understand why 'path' has to be non-null. Not only that, but if it *is* null and the module has no __path__, your patch is still going to pass in a null path. So I'm confused. How did you discover the problem? Similarly, I'm confused as to why 'mod=reload(mod)' would be necessary now, but wasn't before. There have been no changes that I see in test_importhooks that would cause that. What was your testing methodology for this? ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:45 Message: Logged In: YES user_id=642545 Okay, this one is actually the patch, not the test case itself. Sheesh. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:41 Message: Logged In: YES user_id=642545 Attached the patch with a better test case. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 15:37 Message: Logged In: YES user_id=642545 Trying to upload the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Fri Sep 17 01:24:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 01:24:24 2004 Subject: [ python-Bugs-1029561 ] test_pep277 fails Message-ID: Bugs item #1029561, was opened at 2004-09-17 01:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: test_pep277 fails Initial Comment: Running regrtest.py: test_pep277 test test_pep277 produced unexpected output: ********************************************************************** *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ^ ------------ + ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ++++++++++++ ^ ********************************************************************** But when running just test_pep277.py: test_directory (__main__.UnicodeFileTests) ... u'\xdf-\u66e8\u66e9\u66eb' ok test_failures (__main__.UnicodeFileTests) ... ok test_listdir (__main__.UnicodeFileTests) ... ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] [u'Gr\xfc\xdf-Gott', u'abc', u'ascii', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] ok test_open (__main__.UnicodeFileTests) ... ok test_rename (__main__.UnicodeFileTests) ... ok ---------------------------------------------------------------------- Ran 5 tests in 0.109s OK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 From noreply at sourceforge.net Fri Sep 17 01:25:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 01:25:34 2004 Subject: [ python-Bugs-1029561 ] test_pep277 fails Message-ID: Bugs item #1029561, was opened at 2004-09-17 01:24 Message generated for change (Comment added) made by imbaczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: test_pep277 fails Initial Comment: Running regrtest.py: test_pep277 test test_pep277 produced unexpected output: ********************************************************************** *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ^ ------------ + ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ++++++++++++ ^ ********************************************************************** But when running just test_pep277.py: test_directory (__main__.UnicodeFileTests) ... u'\xdf-\u66e8\u66e9\u66eb' ok test_failures (__main__.UnicodeFileTests) ... ok test_listdir (__main__.UnicodeFileTests) ... ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] [u'Gr\xfc\xdf-Gott', u'abc', u'ascii', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] ok test_open (__main__.UnicodeFileTests) ... ok test_rename (__main__.UnicodeFileTests) ... ok ---------------------------------------------------------------------- Ran 5 tests in 0.109s OK ---------------------------------------------------------------------- >Comment By: Marel Baczynski (imbaczek) Date: 2004-09-17 01:25 Message: Logged In: YES user_id=838849 Forgot: Windows XP SP1, Python 2.4a3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 From noreply at sourceforge.net Fri Sep 17 01:30:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 01:30:12 2004 Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k Message-ID: Bugs item #989338, was opened at 2004-07-12 13:11 Message generated for change (Comment added) made by imbaczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_unicode_file fails on win2k Initial Comment: >>> test_support.verbose = 1 >>> test_unicode_file.test_main() test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 178, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_ENCODED+ext, True) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 112, in _do_directory os.mkdir(make_name) OSError: [Errno 22] Invalid argument: '@test-??.dir' ====================================================================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 170, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 154, in _test_equivalent f = file(filename1, "w") IOError: [Errno 2] No such file or directory: '@test-??' ====================================================================== ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\apps\Python24\lib\test\test_unicode_file.py", line 164, in test_single_files self._test_single(TESTFN_ENCODED) File "C:\apps\Python24\lib\test\test_unicode_file.py", line 136, in _test_single f = file(filename, "w") IOError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- Ran 3 tests in 0.061s FAILED (errors=3) Traceback (most recent call last): File "", line 1, in -toplevel- test_unicode_file.test_main() File "C:\apps\Python24\lib\test\test_unicode_file.py", line 191, in test_main run_suite(suite) File "C:\apps\Python24\lib\test\test_support.py", line 274, in run_suite raise TestFailed(msg) TestFailed: errors occurred; run in verbose mode for details >>> This is Python2.4a1 on win2k pro ---------------------------------------------------------------------- Comment By: Marel Baczynski (imbaczek) Date: 2004-09-17 01:30 Message: Logged In: YES user_id=838849 I have the very same errors as quiver on WinXP SP1, Python 2.4a3, NTFS, locale Polish. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-07 16:37 Message: Logged In: YES user_id=671362 I can reproduce this in Python 2.4a3 on Win 2K SP4(locale is set to Japanese). File system is NTFS. But on my box, test_single_files passes OK. Only test_equivalent_files and test_directories raise ERROR. Here is the result. test_unicode_file test_directories (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ok ============================================== ======================== ERROR: test_directories (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 185, in test_directories self._do_directory(TESTFN_ENCODED+ext, TESTFN_UNICODE+ext, True) File "C:\Python24\lib\test\test_unicode_file.py", line 114, in _do_directory os.chdir(chdir_name) OSError: [Errno 2] No such file or directory: u'@test-\xe0 \xf2.dir' ============================================== ======================== ERROR: test_equivalent_files (test.test_unicode_file.TestUnicodeFiles) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "C:\Python24\lib\test\test_unicode_file.py", line 176, in test_equivalent_files self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE) File "C:\Python24\lib\test\test_unicode_file.py", line 157, in _test_equivalent self._do_equivilent(filename1, filename2) File "C:\Python24\lib\test\test_unicode_file.py", line 67, in _do_equivilent os.stat(filename2)) OSError: [Errno 2] No such file or directory: u'@test-\xe0\xf2' ------------------------------------------------------------ ---------- Ran 3 tests in 0.070s FAILED (errors=2) test test_unicode_file failed -- errors occurred; run in verbose mode for details 1 test failed: test_unicode_file ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-09-07 08:56 Message: Logged In: YES user_id=358087 Yes it does :-( I have a winXP on IBM T-40. The other language that is installed is Hebrew. The problem that when encoding TESTFN_UNICODE with the file system ecoding (mbcs) the resulted string is "@test-??" which is not a legal file name on windows ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 08:31 Message: Logged In: YES user_id=80475 Does this still fail for you in Py2.4a3 ? If not, please note the result and close the bug. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-18 08:44 Message: Logged In: YES user_id=358087 File system is NTFS. winver gives: Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 18:55 Message: Logged In: YES user_id=21627 Are you using a FAT partition? What precise version string do you get in winver.exe? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-07-13 08:10 Message: Logged In: YES user_id=358087 Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro. Any other data I can send? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-12 18:35 Message: Logged In: YES user_id=31435 Peculiar -- it works fine on WinXP Pro, which ought to work the same as Win2K here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470 From noreply at sourceforge.net Fri Sep 17 06:43:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 06:43:12 2004 Subject: [ python-Bugs-1025392 ] help() does not check for chm file Message-ID: Bugs item #1025392, was opened at 2004-09-09 15:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: help() does not check for chm file Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-09-16 23:43 Message: Logged In: YES user_id=149084 It appears that Raymond customized his IDLE help to add the chm entry. On Windows, EditorWindow.__init__() will try to locate the .chm file. If it fails, it will go out to python.org for the html docs. F1/Python Docs uses os.startfile() to access the .chm file or the python.org url. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2004-09-10 06:37 Message: Logged In: YES user_id=285587 Thanks Martin. Also thanks to Raymond for his comments and to George for setting out the problem more clearly. Colin W. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 05:55 Message: Logged In: YES user_id=671362 > Notice that Python 2.4 has not been released yet, so there is > no official HTML tarball. A prerelease HTML tarball is available > from > http://www.python.org/dev/doc/python-docs-devel.tar.bz2 It's my fault. I didn't know that. Thanks, Martin. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 04:11 Message: Logged In: YES user_id=21627 If anybody wants to tackle this issue: it is possible to decompile the chm into html files. I propose the following procedure: hh -decompile c:\python24\doc\html c:\python24 \python24.chm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 03:53 Message: Logged In: YES user_id=21627 I see. This is not a bug in IDLE, though - press F1, or select Help/Python Docs to see how IDLE does find the documentation. It is more a problem of the help() function, which does not know about the chm file; changing the subject accordingly. Notice that Python 2.4 has not been released yet, so there is no official HTML tarball. A prerelease HTML tarball is available from http://www.python.org/dev/doc/python-docs-devel.tar.bz2 Raymond, what versin of IDLE are you looking at? In the one shipped with 2.4a3 (IDLE 1.1a3), I see three menu entries: no Chm entry, but the "Python Docs F1" entry brings up the chm file. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 03:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 02:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 01:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 17 06:47:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 06:47:49 2004 Subject: [ python-Bugs-1027566 ] Argument missing from calltip for new-style class init Message-ID: Bugs item #1027566, was opened at 2004-09-13 17:17 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027566&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Loren Guthrie (lguthrie) >Assigned to: Kurt B. Kaiser (kbk) Summary: Argument missing from calltip for new-style class init Initial Comment: The calltip for __init__ on new-style classes doesn't show the arguments like it does for old-style classes. >>> import idlelib.CallTips >>> class OldClass: ... """Old-style class""" ... def __init__(self, x): ... self.x = x ... >>> idlelib.CallTips.get_arg_text(OldClass) '(x)\nOld-style class' >>> class NewClass(object): ... """New-style class""" ... def __init__(self, x): ... self.x = x ... >>> idlelib.CallTips.get_arg_text(NewClass) 'New-style class' Changing CallTips.py line 134 (in get_arg_text) from if type(ob)==types.ClassType: to if type(ob) in [types.ClassType, types.TypeType]: SEEMS to fix the problem, but I have no idea what side-effects this might have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027566&group_id=5470 From noreply at sourceforge.net Fri Sep 17 08:33:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 08:33:06 2004 Subject: [ python-Bugs-1025392 ] help() does not check for chm file Message-ID: Bugs item #1025392, was opened at 2004-09-09 22:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: help() does not check for chm file Initial Comment: Idle looks for the html docs In the source package there are lots of .tex files, must these be converted to HTML, if so how? Using Windows XP ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-17 08:33 Message: Logged In: YES user_id=21627 Assuming everybody agrees that the original issue is resolved, I close this report. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-09-17 06:43 Message: Logged In: YES user_id=149084 It appears that Raymond customized his IDLE help to add the chm entry. On Windows, EditorWindow.__init__() will try to locate the .chm file. If it fails, it will go out to python.org for the html docs. F1/Python Docs uses os.startfile() to access the .chm file or the python.org url. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2004-09-10 13:37 Message: Logged In: YES user_id=285587 Thanks Martin. Also thanks to Raymond for his comments and to George for setting out the problem more clearly. Colin W. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 12:55 Message: Logged In: YES user_id=671362 > Notice that Python 2.4 has not been released yet, so there is > no official HTML tarball. A prerelease HTML tarball is available > from > http://www.python.org/dev/doc/python-docs-devel.tar.bz2 It's my fault. I didn't know that. Thanks, Martin. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 11:11 Message: Logged In: YES user_id=21627 If anybody wants to tackle this issue: it is possible to decompile the chm into html files. I propose the following procedure: hh -decompile c:\python24\doc\html c:\python24 \python24.chm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 10:53 Message: Logged In: YES user_id=21627 I see. This is not a bug in IDLE, though - press F1, or select Help/Python Docs to see how IDLE does find the documentation. It is more a problem of the help() function, which does not know about the chm file; changing the subject accordingly. Notice that Python 2.4 has not been released yet, so there is no official HTML tarball. A prerelease HTML tarball is available from http://www.python.org/dev/doc/python-docs-devel.tar.bz2 Raymond, what versin of IDLE are you looking at? In the one shipped with 2.4a3 (IDLE 1.1a3), I see three menu entries: no Chm entry, but the "Python Docs F1" entry brings up the chm file. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-10 10:01 Message: Logged In: YES user_id=671362 Martin: > Why do you say IDLE looks for the html docs? Start up an idle(or an interpreter), type help(), and type 'and'. Then you can understand what Colin is trying to say. >>> help() ...(snip) help> and If a PYTHONDOCS environ variable is given to the directory of html files, the interpreter parses them and show the document of 'and'. Otherwise, you get the message: Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. You can solve this problem by downloading html docs for 2.3.* from http://www.python.org/doc/current/download.html, but you can't for 2.4*. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-10 09:10 Message: Logged In: YES user_id=80475 Martin, the IDLE help menu has four entries: 1) About IDLE -- brings up a Tk window 2) IDLE Help -- brings up another Tk window 3) Python Docs F1 -- browses http://www.python.org/doc/current/ 4) Chm -- calls up the chm file Colin, pressing F1 should take you to on-line html docs. Normally windows users access the CHM option when they want to browse documentation locally. I've never been able to convert TeX files to HTML on Windows. Fortunately, there is almost no need. If this answers your question. please close the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 08:37 Message: Logged In: YES user_id=21627 Why do you say IDLE looks for the html docs? On Windows, it doesn't - it looks for the chm file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025392&group_id=5470 From noreply at sourceforge.net Fri Sep 17 09:15:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 09:15:31 2004 Subject: [ python-Bugs-754449 ] Exceptions when a thread exits Message-ID: Bugs item #754449, was opened at 2003-06-14 12:32 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 Category: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable jgoerzen@christoph:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive LocalExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive RemoteExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2004-09-17 09:15 Message: Logged In: YES user_id=769182 I have this bug on Python 2.2.3 : occasionally getting a very similar stack when my daemon thread exits. I don't get the error for non-daemon threads. My problem seems pretty similar to carlosayam's problem, described in June. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-03 22:01 Message: Logged In: YES user_id=357491 For 2.3, rev.1.38.6.1 has the required fixes (required also backporting rev. 1.41 from HEAD). Thanks to everyone who tried to help with this nasty thing. And a special thanks to the Mnet guys for giving me a way to reproduce this bug consistently. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-03 05:57 Message: Logged In: YES user_id=357491 Fixed in 2.4 thanks to rev. 1.42 to Lib/threading. Don't know if this will be backported to 2.3 . Possible, but need someone else to agree first. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-03 08:05 Message: Logged In: YES user_id=990060 I don't understand one thing: how can python shut down itself and, at the same time, keep a python code running in a daemonised thread? or is that thread running in a different "threaded" python byte-code interpreter? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-03 07:25 Message: Logged In: YES user_id=31435 Brett, FYI, a daemon thread differs from a non-daemon thread in only one respect: Python shuts down when only daemon threads remain. It waits for non-daemon threads to finish. So a daemon thread can keep running after the interpreter has torn itself down completely. For that reason, problems in daemon threads doing non-trivial things are almost guaranteed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-03 07:08 Message: Logged In: YES user_id=357491 Yep, that is how Python cleans up a module; sets everything in the module to None and then removes it from sys.modules . As for your case, I don't know enough about daemonized threads. My patch for this only tries to let the exception make it to the top without 'threading' hiding the exception by causing its own exception from interpreter shutdown. In other words I don't know if this is a related issue or not. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-03 05:01 Message: Logged In: YES user_id=990060 bcannon said on 2004-02-17 >> Does anyone know how to cause this error in isolation? I'm getting the same error when I start a new thread, daemonise it and the thread goes into a very slow database operation (loading a large object); meanwhile the main thread starts a GUI; then I close the window, exiting the main loop and the python interpreter ends (or tries to end.) In relation to bcannon comment on how to reproduce the error (setting all variables to None in the module), my guess is that while exiting, the python interpreter is somehow freeing all variables in the module (cleaning the module or something), but the module is still running and that raises the error... is this possible? Note: if the thread is not daemonised, the problem desapears but the script (the python interpreter) takes a while to finish. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-17 06:36 Message: Logged In: YES user_id=357491 How to reproduce the bug: * Follow the instructions at http://mnetproject.org/repos/ on how to get a copy of the in-dev version of mnet (I used the instructions for using wget and it worked fine). * Run ``python setup.py``. Do realize that this app will download other Python code (crypto stuff mostly) to finish its install. Takes up about 54 MB on my machine after it is compiled. * Run ``python setup.py test -a``. This executes the testing suite. The bug manifests itself after the testing suite finishes execution. This will consistently cause the bug every time. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 20:45 Message: Logged In: YES user_id=357491 Discovered this is not fixed after all (previous fix didn't go far enough; still needed, though). Patch 954922 is the second attempt to fix this. This time, though, I had code that could trigger the problem reliably and thus this should be the proper, and final, fix. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 23:36 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 23:32 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-03 05:29 Message: Logged In: YES user_id=357491 To force this error I inserted code to set all attributes of the threading module to None and then throw and exception. After commenting out the two calls to currentThread in _Condition the thrown exception to trigger the problem propogated to the top correctly. I did have the clean-up function give out since I set *everything* to None, but it doesn't look like a normal issue as shown in the exception traceback in the OP. I don't think it is an issue. So it seems commenting the two calls to currentThread in _Condition solves the problem. But since this is threading code and the comment explicitly states it is for the side-effect I am going to try to get a second opinion. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-17 05:59 Message: Logged In: YES user_id=357491 Does anyone know how to cause this error in isolation? I have tried a bunch of different ways but cannot cause an exception to be raised at the correct point in Threading.__bootstrap() to lead to self.__stop() to be called while the interpreter is tearing itself down. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-10 02:18 Message: Logged In: YES user_id=357491 After staring at the code, I am not even sure if the calls for its side- effect are needed. If you call currentThread(), it either returns a value from _active which is a dict of running Thread instances indexed by thread idents, or a new _DummyThread instance that inserts itself into _active. Now the two calls in the _Condition class are purely for this possible side-effect. And yet at no point is anything from _active, through currentThread or direct access, even touched by a _Condition method. The only chance this might be an issue is if a _Condition instance uses an RLock instance for its locking, which is the default behavior. But this still makes the side-effect need useless. RLocks will call currentThread on their own and since this is all in the same thread the result won't change. And in this specific case of this bug, the _Condition instance is created with a Lock instance since that is what the Thread instance uses for constructing the _Condition instance it use, which is just thread.allocate_lock() which is obviously not an RLock. In other words I can't find the point to the side-effect in _Condition. I will try to come up with some testing code that reproduces the error and then see if just removing the calls in _Condition remove the error and still pass the regression tests. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2003-06-16 15:26 Message: Logged In: YES user_id=491567 I can confirm that this behavior is not present in Python 2.2 in the same version that I am using to test against Python 2.3. I will be on vacation for most of this and next week. I'll try to get to the logging script before I leave, but I might not get to it until I return. FYI, you can also obtain OfflineIMAP at http://quux.org/devel/offlineimap. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 08:58 Message: Logged In: YES user_id=357491 OK, following Tim's advice I checked and it seems that Thread calls a method while shutting itself down that calls Condition.notifyAll which calls currentThread which is a global. It would appear that offlineimap is leaving its threads running, the program gets shut down, the threads raise an error while shutting down (probably because things are being torn down), this triggers the stopping method in Thread, and this raises its own exception because of the teardown which is what we are seeing as the TypeError. So the question is whether Condition should store a local reference to currentThread or not. It is not the most pure solution since this shutdown issue is not Condition's, but the only other solution I can think of is to have Thread keep a reference to currentThread, inject it into the current frame's global namespace, call Condition.notifyAll, and then remove the reference from the frame again. I vote for the cleaner, less pure solution. =) Am I insane on this or does it at least sound like this is the problem and proper solution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 08:19 Message: Logged In: YES user_id=357491 Nuts. For some reason I thought the OP had said when threads were exiting. I will ask on python-dev for a good explanation of what happens when Python is shutting down. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-16 03:05 Message: Logged In: YES user_id=31435 Note that the OP said "when my application exits". When Python is tearing down the universe, it systematically sets module-global bindings to None. currentThread() is a module global. I can't make more time for this now, so for more info talk about it on Python-Dev. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 01:44 Message: Logged In: YES user_id=357491 Well, I'm stumped. I checked the diff from when 2.2 was initially released until now and the only change that seems to be related to any of this is that what is returned by currentThread is not saved in a variable. But since the error is the calling of currentThread itself and not saving the return value I don't see how that would affect anything. I also went through offlineimap but I didn't see anything there that seemed to be setting currentThread to None. Although since several files do ``import *`` so there still is a possibility of overwriting currentThread locally. So, for my owning learning and to help solve this, I have written a tracing function that writes to stderr using the logging package when it detects that either currentThread or threading.currentThread has been set to None, locally or globally (I assume the code is not injecting into builtins so I didn't bother checking there). The file is named tracer.py and I have attached it to this bug report. If you can execute ``sys.settrace(tracer.trace_currentThread)`` before offlinemap starts executing and immediately within each thread (it has to be called in *every* thread since tracing functions are no inherited from the main thread) it should print out a message when currentThread becomes None. If you *really* want to make this robust you can also have it check sys.modules['threading'] every time as well, but I figure there is not going to be much renaming and masking of currentThread. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-15 10:44 Message: Logged In: YES user_id=60903 Please see http://packages.debian.org/unstable/mail/offlineimap.html or for the tarball: http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 10:19 Message: Logged In: YES user_id=357491 I went to the FTP site and all I found was some huge, compressed files (after changing the path to ftp://ftp.debian.org/ debian/dists/sid/main/source); no specific program called offlinemap. If it is in one of those files can you just add the file to the bug report? As for the reported bug, it looks like currentThread is being redefined, although how that is happening is beyond me. I checked the 'threading' module and no where is currentThread redefined which could lead to None. Has the app being run been changed at all since Python 2.2 was released? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 From noreply at sourceforge.net Fri Sep 17 11:55:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 11:55:36 2004 Subject: [ python-Bugs-1029561 ] test_pep277 fails Message-ID: Bugs item #1029561, was opened at 2004-09-17 08:24 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: test_pep277 fails Initial Comment: Running regrtest.py: test_pep277 test test_pep277 produced unexpected output: ********************************************************************** *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ^ ------------ + ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] ? ++++++++++++ ^ ********************************************************************** But when running just test_pep277.py: test_directory (__main__.UnicodeFileTests) ... u'\xdf-\u66e8\u66e9\u66eb' ok test_failures (__main__.UnicodeFileTests) ... ok test_listdir (__main__.UnicodeFileTests) ... ['???', '???', '????-???', '??????', '????????????', '?????\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] [u'Gr\xfc\xdf-Gott', u'abc', u'ascii', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] ok test_open (__main__.UnicodeFileTests) ... ok test_rename (__main__.UnicodeFileTests) ... ok ---------------------------------------------------------------------- Ran 5 tests in 0.109s OK ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-17 18:55 Message: Logged In: YES user_id=671362 Same for me. Fail for regrtest.py, but OK for test_277.py in isolation. (Python 2.4a3, Windows 2K SP4, locale:Japan) But my output is a bit different from yours. test test_pep277 produced unexpected output: ********************************************** ************************ *** mismatch between line 3 of expected output and line 3 of actual output: - ['???', '???', '??????', '????????????', '????G\xdf', 'Ge??- sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii'] + ['??????', '??\x82\xf1\x84t\x83\xa1s', '?\x9eG?', 'Grus- Gott', 'abc', 'ascii', '\x82\xc9\x82\xdb\x82\xf1', '\x83\xa1\x83 \xc3\x83\xc7?-\x83\xd0\x83\xbf?', '\x84H\x84t\x84\x82 \x84p\x84r\x84\x83\x84\x84\x84r\x84\x85\x84z\x84\x84\x84u'] ********************************************** ************************ This reminds me of the next thread: * More joy with test_strptime http://mail.python.org/pipermail/python-dev/2004- July/046046.html ---------------------------------------------------------------------- Comment By: Marel Baczynski (imbaczek) Date: 2004-09-17 08:25 Message: Logged In: YES user_id=838849 Forgot: Windows XP SP1, Python 2.4a3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&group_id=5470 From noreply at sourceforge.net Fri Sep 17 18:15:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 18:15:50 2004 Subject: [ python-Bugs-1028697 ] Problem linking on windows using mingw32 and C++ Message-ID: Bugs item #1028697, was opened at 2004-09-15 13:28 Message generated for change (Comment added) made by woodsplitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steve Menard (devilwolf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking on windows using mingw32 and C++ Initial Comment: When create a python extension in C++ and using ming32 to compile it, distutil will try to use 'cc' as the linker. The problem is that the CCompiler.link() method will substitude the linker it has found in linker_exe or linker_so with the first part of compiler_cxx. (lines 175-176) So adding the following line to Mingw32Compiler, near line 296 compiler_cxx='g++ -mno-cygwin -O -Wall', Fixes it for me. Quickly looking at the CygwinCompiler indicates it would suffer from he same problem. ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2004-09-17 12:15 Message: Logged In: YES user_id=414645 Is this a duplicate of the following two bug reports? http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165 http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=832159 The first of those two was closed with a notice that the patch is in CVS; the second is still open. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 From noreply at sourceforge.net Fri Sep 17 18:33:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 18:33:37 2004 Subject: [ python-Bugs-754449 ] Exceptions when a thread exits Message-ID: Bugs item #754449, was opened at 2003-06-14 03:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 Category: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable jgoerzen@christoph:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive LocalExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive RemoteExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-17 09:33 Message: Logged In: YES user_id=357491 Python 2.2 is no longer actively maintained, so I wouldn't count on the fix being backported. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2004-09-17 00:15 Message: Logged In: YES user_id=769182 I have this bug on Python 2.2.3 : occasionally getting a very similar stack when my daemon thread exits. I don't get the error for non-daemon threads. My problem seems pretty similar to carlosayam's problem, described in June. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-03 13:01 Message: Logged In: YES user_id=357491 For 2.3, rev.1.38.6.1 has the required fixes (required also backporting rev. 1.41 from HEAD). Thanks to everyone who tried to help with this nasty thing. And a special thanks to the Mnet guys for giving me a way to reproduce this bug consistently. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 20:57 Message: Logged In: YES user_id=357491 Fixed in 2.4 thanks to rev. 1.42 to Lib/threading. Don't know if this will be backported to 2.3 . Possible, but need someone else to agree first. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-02 23:05 Message: Logged In: YES user_id=990060 I don't understand one thing: how can python shut down itself and, at the same time, keep a python code running in a daemonised thread? or is that thread running in a different "threaded" python byte-code interpreter? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-02 22:25 Message: Logged In: YES user_id=31435 Brett, FYI, a daemon thread differs from a non-daemon thread in only one respect: Python shuts down when only daemon threads remain. It waits for non-daemon threads to finish. So a daemon thread can keep running after the interpreter has torn itself down completely. For that reason, problems in daemon threads doing non-trivial things are almost guaranteed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-02 22:08 Message: Logged In: YES user_id=357491 Yep, that is how Python cleans up a module; sets everything in the module to None and then removes it from sys.modules . As for your case, I don't know enough about daemonized threads. My patch for this only tries to let the exception make it to the top without 'threading' hiding the exception by causing its own exception from interpreter shutdown. In other words I don't know if this is a related issue or not. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-02 20:01 Message: Logged In: YES user_id=990060 bcannon said on 2004-02-17 >> Does anyone know how to cause this error in isolation? I'm getting the same error when I start a new thread, daemonise it and the thread goes into a very slow database operation (loading a large object); meanwhile the main thread starts a GUI; then I close the window, exiting the main loop and the python interpreter ends (or tries to end.) In relation to bcannon comment on how to reproduce the error (setting all variables to None in the module), my guess is that while exiting, the python interpreter is somehow freeing all variables in the module (cleaning the module or something), but the module is still running and that raises the error... is this possible? Note: if the thread is not daemonised, the problem desapears but the script (the python interpreter) takes a while to finish. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 21:36 Message: Logged In: YES user_id=357491 How to reproduce the bug: * Follow the instructions at http://mnetproject.org/repos/ on how to get a copy of the in-dev version of mnet (I used the instructions for using wget and it worked fine). * Run ``python setup.py``. Do realize that this app will download other Python code (crypto stuff mostly) to finish its install. Takes up about 54 MB on my machine after it is compiled. * Run ``python setup.py test -a``. This executes the testing suite. The bug manifests itself after the testing suite finishes execution. This will consistently cause the bug every time. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 11:45 Message: Logged In: YES user_id=357491 Discovered this is not fixed after all (previous fix didn't go far enough; still needed, though). Patch 954922 is the second attempt to fix this. This time, though, I had code that could trigger the problem reliably and thus this should be the proper, and final, fix. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 14:36 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 14:32 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-02 20:29 Message: Logged In: YES user_id=357491 To force this error I inserted code to set all attributes of the threading module to None and then throw and exception. After commenting out the two calls to currentThread in _Condition the thrown exception to trigger the problem propogated to the top correctly. I did have the clean-up function give out since I set *everything* to None, but it doesn't look like a normal issue as shown in the exception traceback in the OP. I don't think it is an issue. So it seems commenting the two calls to currentThread in _Condition solves the problem. But since this is threading code and the comment explicitly states it is for the side-effect I am going to try to get a second opinion. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-16 20:59 Message: Logged In: YES user_id=357491 Does anyone know how to cause this error in isolation? I have tried a bunch of different ways but cannot cause an exception to be raised at the correct point in Threading.__bootstrap() to lead to self.__stop() to be called while the interpreter is tearing itself down. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-09 17:18 Message: Logged In: YES user_id=357491 After staring at the code, I am not even sure if the calls for its side- effect are needed. If you call currentThread(), it either returns a value from _active which is a dict of running Thread instances indexed by thread idents, or a new _DummyThread instance that inserts itself into _active. Now the two calls in the _Condition class are purely for this possible side-effect. And yet at no point is anything from _active, through currentThread or direct access, even touched by a _Condition method. The only chance this might be an issue is if a _Condition instance uses an RLock instance for its locking, which is the default behavior. But this still makes the side-effect need useless. RLocks will call currentThread on their own and since this is all in the same thread the result won't change. And in this specific case of this bug, the _Condition instance is created with a Lock instance since that is what the Thread instance uses for constructing the _Condition instance it use, which is just thread.allocate_lock() which is obviously not an RLock. In other words I can't find the point to the side-effect in _Condition. I will try to come up with some testing code that reproduces the error and then see if just removing the calls in _Condition remove the error and still pass the regression tests. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2003-06-16 06:26 Message: Logged In: YES user_id=491567 I can confirm that this behavior is not present in Python 2.2 in the same version that I am using to test against Python 2.3. I will be on vacation for most of this and next week. I'll try to get to the logging script before I leave, but I might not get to it until I return. FYI, you can also obtain OfflineIMAP at http://quux.org/devel/offlineimap. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 23:58 Message: Logged In: YES user_id=357491 OK, following Tim's advice I checked and it seems that Thread calls a method while shutting itself down that calls Condition.notifyAll which calls currentThread which is a global. It would appear that offlineimap is leaving its threads running, the program gets shut down, the threads raise an error while shutting down (probably because things are being torn down), this triggers the stopping method in Thread, and this raises its own exception because of the teardown which is what we are seeing as the TypeError. So the question is whether Condition should store a local reference to currentThread or not. It is not the most pure solution since this shutdown issue is not Condition's, but the only other solution I can think of is to have Thread keep a reference to currentThread, inject it into the current frame's global namespace, call Condition.notifyAll, and then remove the reference from the frame again. I vote for the cleaner, less pure solution. =) Am I insane on this or does it at least sound like this is the problem and proper solution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 23:19 Message: Logged In: YES user_id=357491 Nuts. For some reason I thought the OP had said when threads were exiting. I will ask on python-dev for a good explanation of what happens when Python is shutting down. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-15 18:05 Message: Logged In: YES user_id=31435 Note that the OP said "when my application exits". When Python is tearing down the universe, it systematically sets module-global bindings to None. currentThread() is a module global. I can't make more time for this now, so for more info talk about it on Python-Dev. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 16:44 Message: Logged In: YES user_id=357491 Well, I'm stumped. I checked the diff from when 2.2 was initially released until now and the only change that seems to be related to any of this is that what is returned by currentThread is not saved in a variable. But since the error is the calling of currentThread itself and not saving the return value I don't see how that would affect anything. I also went through offlineimap but I didn't see anything there that seemed to be setting currentThread to None. Although since several files do ``import *`` so there still is a possibility of overwriting currentThread locally. So, for my owning learning and to help solve this, I have written a tracing function that writes to stderr using the logging package when it detects that either currentThread or threading.currentThread has been set to None, locally or globally (I assume the code is not injecting into builtins so I didn't bother checking there). The file is named tracer.py and I have attached it to this bug report. If you can execute ``sys.settrace(tracer.trace_currentThread)`` before offlinemap starts executing and immediately within each thread (it has to be called in *every* thread since tracing functions are no inherited from the main thread) it should print out a message when currentThread becomes None. If you *really* want to make this robust you can also have it check sys.modules['threading'] every time as well, but I figure there is not going to be much renaming and masking of currentThread. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-15 01:44 Message: Logged In: YES user_id=60903 Please see http://packages.debian.org/unstable/mail/offlineimap.html or for the tarball: http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 01:19 Message: Logged In: YES user_id=357491 I went to the FTP site and all I found was some huge, compressed files (after changing the path to ftp://ftp.debian.org/ debian/dists/sid/main/source); no specific program called offlinemap. If it is in one of those files can you just add the file to the bug report? As for the reported bug, it looks like currentThread is being redefined, although how that is happening is beyond me. I checked the 'threading' module and no where is currentThread redefined which could lead to None. Has the app being run been changed at all since Python 2.2 was released? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 From noreply at sourceforge.net Fri Sep 17 23:40:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 23:41:02 2004 Subject: [ python-Bugs-1030118 ] email.Utils not mentioned Message-ID: Bugs item #1030118, was opened at 2004-09-17 17:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030118&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Blaine (jblaine) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils not mentioned Initial Comment: I read the following and had to track down why 'email.make_msgid()' was failing. Turns out I need to import email.Utils of course, but the name of the module to import is not even mentioned in the docs. It states they come 'with the email package' only. ... 12.2.9 Miscellaneous utilities There are several useful utilities provided with the email package. quote(str) Return a new string with backslashes in str replaced by two backslashes, and double quotes replaced by backslash-double quote. .... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030118&group_id=5470 From noreply at sourceforge.net Sat Sep 18 00:10:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 00:10:56 2004 Subject: [ python-Bugs-1030125 ] rfc822 __iter__ problem Message-ID: Bugs item #1030125, was opened at 2004-09-17 22:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 __iter__ problem Initial Comment: >>> from urllib2 import urlopen >>> a = urlopen('http://www.voidspace.org.uk') >>> i = a.info() >>> for entry in i: print entry Traceback (most recent call last): File "", line 1, in -toplevel- for entry in i: print entry File "D:\PYTHON23\lib\rfc822.py", line 390, in __getitem__ return self.dict[name.lower()] AttributeError: 'int' object has no attribute 'lower' Iterating over an rfc822 message (above done from urllib2) causes an exception. Could be fixed by returning an iter(self.dict) from the __iter__ method. This bug looks similar to bug 1017329. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 From noreply at sourceforge.net Sat Sep 18 09:11:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 09:11:12 2004 Subject: [ python-Bugs-1030249 ] socket is not garbage-collected under specific circumstances Message-ID: Bugs item #1030249, was opened at 2004-09-18 09:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030249&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket is not garbage-collected under specific circumstances Initial Comment: [forwarded from http://bugs.debian.org/271169] seen with current 2.3 branch and 2.4a3. bug submitter writes: Hello. I have found strange behaivoir: when my class uses xml.parsers.expat parser then the attributes, assigned to this class is not garbage-collected. I've attached a little script to show this. The test is simple: script listening to port 1024 and awaiting first connection. upon incoming connect it creates the class instance in question and then _destroys_all_ that it just created. Then sleeps for 5 secods. If the bug is not activated (rem the 8th line) then the connection is closed immidiatedly after estabilishing. If activated - only after script exit. So the test is simple: start script in one console run the "telnet 127.0.0.1 1024" in other console. see that telnet waits 5 seconds instead of immediate disconnect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030249&group_id=5470 From noreply at sourceforge.net Sat Sep 18 09:15:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 09:15:53 2004 Subject: [ python-Bugs-1030250 ] distutils' dry-run wants to create some real build dirs Message-ID: Bugs item #1030250, was opened at 2004-09-18 09:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030250&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: distutils' dry-run wants to create some real build dirs Initial Comment: [forwarded from http://bugs.debian.org/270127] When using the distutils to build a python extension module while using the dry-run option the build fails. It goes like this: frigg:~/FEMesh/mesh$ ./setup.py --dry-run build running build running build_py creating build creating build/lib.linux-sparc64-2.3 creating build/lib.linux-sparc64-2.3/Mesh copying Mesh/__init__.py -> build/lib.linux-sparc64-2.3/Mesh creating build/lib.linux-sparc64-2.3/Mesh/Delaunay copying Mesh/Delaunay/__init__.py -> build/lib.linux-sparc64-2.3/Mesh/Delaunay running build_ext building 'Mesh.Delaunay._qhull' extension creating build/temp.linux-sparc64-2.3 error: could not create 'build/temp.linux-sparc64-2.3': No such file or directory frigg:~/FEMesh/mesh$ frigg:~/FEMesh/mesh$ DISTUTILS_DEBUG=true ./setup.py --dry-run build Distribution.parse_config_files(): options (after parsing config files): no commands known yet options (after parsing command line): option dict for 'build' command: {} running build Distribution.get_command_obj(): creating 'build' command object running build_py Distribution.get_command_obj(): creating 'build_py' command object creating build creating build/lib.linux-sparc64-2.3 creating build/lib.linux-sparc64-2.3/Mesh copying Mesh/__init__.py -> build/lib.linux-sparc64-2.3/Mesh creating build/lib.linux-sparc64-2.3/Mesh/Delaunay copying Mesh/Delaunay/__init__.py -> build/lib.linux-sparc64-2.3/Mesh/Delaunay running build_ext Distribution.get_command_obj(): creating 'build_ext' command object building 'Mesh.Delaunay._qhull' extension creating build/temp.linux-sparc64-2.3 Traceback (most recent call last): File "./setup.py", line 27, in ? ext_modules=[module_qhull]) File "/usr/lib/python2.3/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.3/distutils/dist.py", line 907, in run_commands self.run_command(cmd) File "/usr/lib/python2.3/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/usr/lib/python2.3/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/usr/lib/python2.3/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.3/distutils/dist.py", line 927, in run_command cmd_obj.run() File "/usr/lib/python2.3/distutils/command/build_ext.py", line 269, in run self.build_extensions() File "/usr/lib/python2.3/distutils/command/build_ext.py", line 395, in build_extensions self.build_extension(ext) File "/usr/lib/python2.3/distutils/command/build_ext.py", line 460, in build_extension depends=ext.depends) File "/usr/lib/python2.3/distutils/ccompiler.py", line 691, in compile depends, extra_postargs) File "/usr/lib/python2.3/distutils/ccompiler.py", line 417, in _setup_compile self.mkpath(os.path.dirname(obj)) File "/usr/lib/python2.3/distutils/ccompiler.py", line 1042, in mkpath mkpath (name, mode, self.dry_run) File "/usr/lib/python2.3/distutils/dir_util.py", line 79, in mkpath raise DistutilsFileError, distutils.errors.DistutilsFileError: could not create 'build/temp.linux-sparc64-2.3': No such file or directory frigg:~/FEMesh/mesh$ frigg:~/FEMesh/mesh$ mkdir build frigg:~/FEMesh/mesh$ frigg:~/FEMesh/mesh$ ./setup.py --dry-run build running build running build_py creating build/lib.linux-sparc64-2.3 creating build/lib.linux-sparc64-2.3/Mesh copying Mesh/__init__.py -> build/lib.linux-sparc64-2.3/Mesh creating build/lib.linux-sparc64-2.3/Mesh/Delaunay copying Mesh/Delaunay/__init__.py -> build/lib.linux-sparc64-2.3/Mesh/Delaunay running build_ext building 'Mesh.Delaunay._qhull' extension creating build/temp.linux-sparc64-2.3 creating build/temp.linux-sparc64-2.3/Mesh creating build/temp.linux-sparc64-2.3/Mesh/Delaunay gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DMAJOR_VERSION=0 -DMINOR_VERSION=1 -I/usr/include/python2.3 -c Mesh/Delaunay/_qhullmodule.c -o build/temp.linux-sparc64-2.3/Mesh/Delaunay/_qhullmodule.o gcc -pthread -shared build/temp.linux-sparc64-2.3/Mesh/Delaunay/_qhullmodule.o -o build/lib.linux-sparc64-2.3/Mesh/Delaunay/_qhull.so frigg:~/FEMesh/mesh$ frigg:~/FEMesh/mesh$ ls -R build/ build/: temp.linux-sparc64-2.3 build/temp.linux-sparc64-2.3: Mesh build/temp.linux-sparc64-2.3/Mesh: Delaunay build/temp.linux-sparc64-2.3/Mesh/Delaunay: frigg:~/FEMesh/mesh$ rm -rf build/ frigg:~/FEMesh/mesh$ This should show it all. Cheers Floris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030250&group_id=5470 From noreply at sourceforge.net Sat Sep 18 11:59:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 11:59:49 2004 Subject: [ python-Bugs-933795 ] configure not able to find ncurses/curses in Solaris Message-ID: Bugs item #933795, was opened at 2004-04-12 20:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933795&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: stefanparvu (sparvu) Assigned to: Nobody/Anonymous (nobody) Summary: configure not able to find ncurses/curses in Solaris Initial Comment: I am trying to build Python 2.3.3 on Solaris 9 x86. Everything goes fine except that I have some issues with curses module ... It looks like configure is failing to detect curses found /usr/lib or any ncurses installed under system. Other fixes: 1) I had to fix configure script in order to get it running by changing SunOS/5.6 in SunOS/5.* eg. " 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. # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish. OpenBSD/2.* | OpenBSD/3.[01234]) define_xopen_source=no;; # On Solaris 2.6, sys/wait.h is inconsistent in the usage # of union __?sigval. Reported by Stuart Bishop. SunOS/5.*) " Im building python using 2.95 the GNU compiler. The configure command was something like: ./configure --prefix=/usr/local --with-threads --enable-shared My LD_LIBRARY_PATH is defined as: /usr/lib:/opt/sfw/lib:/usr/sfw/lib I have tried passing to the command line LDFLAGS="-L/usr/lib :/usr/sfw/lib -lcurses -ltermcap " ./configure .... without success --- I have found that after compilation there are some warnings about curses module ... *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.9-i86pc-2.3/_curses.so: symbol newscr: referenced symbol not found building '_curses_panel' extension *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses ... which, I think, will end by having no curses module available. >From help() found out these: help> modules Please wait a moment while I gather a list of all available modules... ... _curses_failed getpass py_compile _curses_panel_failed So python 2.3.3 does not biuild 100% clean under Solaris x86 I havent tried this on sparc but most likely same problem is in there too. Please evaluate. stefan ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 11:59 Message: Logged In: YES user_id=21627 This is fixed with said patch. ---------------------------------------------------------------------- Comment By: Ariel Arjona (beerfrick) Date: 2004-08-19 17:45 Message: Logged In: YES user_id=200741 Submitted patch 1012280 https://sourceforge.net/tracker/index.php?func=detail&aid=1012280&group_id=5470&atid=305470 I saw this bug on both 2.3.3 and 2.3.4 on Solaris 8 on SPARC ---------------------------------------------------------------------- Comment By: stefanparvu (sparvu) Date: 2004-04-13 15:30 Message: Logged In: YES user_id=1019660 I think the problem is between GNU gcc compiler and autoconf ... when Im using Sun's compiler and libcurses ... I see no problem. python builds fine without any problem. The problem is visible when Im using gcc and autconf does not pick up the correct libcurses. At the moment Im swithcing to Sun's compiler ... stefan ---------------------------------------------------------------------- Comment By: stefanparvu (sparvu) Date: 2004-04-13 08:48 Message: Logged In: YES user_id=1019660 More details found: Looks like configure is not able to work with Solaris's libcurses at all. I have tried in one system which does not have libncurses at all. configure is failing to work with Solaris's libcurses. checking term.h usability... no checking term.h presence... yes configure: WARNING: term.h: present but cannot be compiled configure: WARNING: term.h: check for missing prerequisite headers? configure: WARNING: term.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for term.h... yes >From config.log configure:4690: checking term.h usability configure:4703: gcc -c -g -O2 conftest.c >&5 In file included from configure:4775: /usr/include/term.h:1034: parse error before `bool' /usr/include/term.h:1034: warning: no semicolon at end of struct or union /usr/include/term.h:1035: warning: data definition has no type or storage class /usr/include/term.h:1060: parse error before `SGTTY' /usr/include/term.h:1060: warning: no semicolon at end of struct or union /usr/include/term.h:1081: parse error before `sgr_mode' /usr/include/term.h:1081: warning: data definition has no type or storage class /usr/include/term.h:1082: parse error before `sgr_faked' /usr/include/term.h:1082: warning: data definition has no type or storage class /usr/include/term.h:1092: parse error before `funckeystarter' /usr/include/term.h:1092: warning: data definition has no type or storage class /usr/include/term.h:1094: parse error before `_fl_rawmode' /usr/include/term.h:1097: warning: data definition has no type or storage class /usr/include/term.h:1101: parse error before `_input_queue' /usr/include/term.h:1101: warning: data definition has no type or storage class /usr/include/term.h:1108: parse error before `*' /usr/include/term.h:1108: warning: data definition has no type or storage class /usr/include/term.h:1111: parse error before `bit_vector' /usr/include/term.h:1111: warning: data definition has no type or storage class /usr/include/term.h:1115: parse error before `check_turn_off' /usr/include/term.h:1115: warning: data definition has no type or storage class /usr/include/term.h:1116: parse error before `non_faked_mode' /usr/include/term.h:1116: warning: data definition has no type or storage class /usr/include/term.h:1117: parse error before `_cur_pair' /usr/include/term.h:1117: warning: data definition has no type or storage class /usr/include/term.h:1118: parse error before `*' /usr/include/term.h:1118: warning: data definition has no type or storage class /usr/include/term.h:1120: parse error before `}' /usr/include/term.h:1207: parse error before `int' /usr/include/term.h:1207: `vidputs' declared as function returning a function /usr/include/term.h:1207: parse error before `)' configure:4706: $? = 1 --- stefan ---------------------------------------------------------------------- Comment By: stefanparvu (sparvu) Date: 2004-04-12 22:13 Message: Logged In: YES user_id=1019660 Regarding this problem looks like 'configure' does not pickup Solaris's curses library. I had to manually pass to configure command libncurses library LDFLAGS="-L/opt/sfw/lib -R/opt/sfw/lib -lncurses" CPPFLAGS="-I/optsfw/include" ./configure --prefix=/usr/local --with-threads --enable-shared Does this mean that python needs libncurses and can not work with Solaris curses library !? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933795&group_id=5470 From noreply at sourceforge.net Sat Sep 18 12:38:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 12:38:17 2004 Subject: [ python-Bugs-1030249 ] socket is not garbage-collected under specific circumstances Message-ID: Bugs item #1030249, was opened at 2004-09-18 09:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030249&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket is not garbage-collected under specific circumstances Initial Comment: [forwarded from http://bugs.debian.org/271169] seen with current 2.3 branch and 2.4a3. bug submitter writes: Hello. I have found strange behaivoir: when my class uses xml.parsers.expat parser then the attributes, assigned to this class is not garbage-collected. I've attached a little script to show this. The test is simple: script listening to port 1024 and awaiting first connection. upon incoming connect it creates the class instance in question and then _destroys_all_ that it just created. Then sleeps for 5 secods. If the bug is not activated (rem the 8th line) then the connection is closed immidiatedly after estabilishing. If activated - only after script exit. So the test is simple: start script in one console run the "telnet 127.0.0.1 1024" in other console. see that telnet waits 5 seconds instead of immediate disconnect. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 12:38 Message: Logged In: YES user_id=21627 This is not a bug in Python. You are creating a cyclic structure (where Session._parser refers to an ExpatParser, the ExpatParser refers to the bound method Session.starttag, and that refers back to the Session object). Python makes no guarantee that the memory for a cyclic structure is released at a specific point; instead, different Python versions may work differently in this matter. The current implementation invokes garbage collection "from time to time", where this more precisely means "after gc.get_threshold()[0] more objects have been allocated than deallocated". Applications should not rely on garbage collection for closing sockets. Instead, they should use an destroy mechanism. In the specific example, just add a destroy method to Session that reads def destroy(self): self.socket.close() self.parser.reset() del self._parser The latter two aren't really necessary, since GC will reclaim the memory of the objects eventually, but explicitly breaking the cycle means that the memory will be reclaimed even before cyclic GC is invoked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030249&group_id=5470 From noreply at sourceforge.net Sat Sep 18 12:38:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 12:38:32 2004 Subject: [ python-Bugs-1030249 ] socket is not garbage-collected under specific circumstances Message-ID: Bugs item #1030249, was opened at 2004-09-18 09:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030249&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: socket is not garbage-collected under specific circumstances Initial Comment: [forwarded from http://bugs.debian.org/271169] seen with current 2.3 branch and 2.4a3. bug submitter writes: Hello. I have found strange behaivoir: when my class uses xml.parsers.expat parser then the attributes, assigned to this class is not garbage-collected. I've attached a little script to show this. The test is simple: script listening to port 1024 and awaiting first connection. upon incoming connect it creates the class instance in question and then _destroys_all_ that it just created. Then sleeps for 5 secods. If the bug is not activated (rem the 8th line) then the connection is closed immidiatedly after estabilishing. If activated - only after script exit. So the test is simple: start script in one console run the "telnet 127.0.0.1 1024" in other console. see that telnet waits 5 seconds instead of immediate disconnect. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 12:38 Message: Logged In: YES user_id=21627 This is not a bug in Python. You are creating a cyclic structure (where Session._parser refers to an ExpatParser, the ExpatParser refers to the bound method Session.starttag, and that refers back to the Session object). Python makes no guarantee that the memory for a cyclic structure is released at a specific point; instead, different Python versions may work differently in this matter. The current implementation invokes garbage collection "from time to time", where this more precisely means "after gc.get_threshold()[0] more objects have been allocated than deallocated". Applications should not rely on garbage collection for closing sockets. Instead, they should use an destroy mechanism. In the specific example, just add a destroy method to Session that reads def destroy(self): self.socket.close() self.parser.reset() del self._parser The latter two aren't really necessary, since GC will reclaim the memory of the objects eventually, but explicitly breaking the cycle means that the memory will be reclaimed even before cyclic GC is invoked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030249&group_id=5470 From noreply at sourceforge.net Sat Sep 18 18:06:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 18:06:57 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:06 Message: Logged In: YES user_id=21627 This is now fixed in tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 I'd be still curious at what point Tcl converts the string "yes" into a boolean, and why this happens only on some installations. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-09 10:43 Message: Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 23:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 14:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 13:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 12:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Sat Sep 18 18:08:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 18:08:30 2004 Subject: [ python-Bugs-1021596 ] Trivial fix for obscure bug in os.urandom() Message-ID: Bugs item #1021596, was opened at 2004-09-03 06:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021596&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Nick Mathewson (nickm) Assigned to: Martin v. L?wis (loewis) Summary: Trivial fix for obscure bug in os.urandom() Initial Comment: The new os.urandom function checks for whether it has set _urandomfd with "if not _urandomfd:" . But this is incorrect; on some systems, if fd 0 has been closed, it is possible for _urandomfd to be 0. Instead, the check should be "if _urandomfd is None". ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:08 Message: Logged In: YES user_id=21627 Thanks, committed as os.py 1.82. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021596&group_id=5470 From noreply at sourceforge.net Sat Sep 18 19:30:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 19:30:58 2004 Subject: [ python-Bugs-1030388 ] os.system exhausts file descriptors Message-ID: Bugs item #1030388, was opened at 2004-09-18 17:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030388&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eray Ozkural (exa) Assigned to: Nobody/Anonymous (nobody) Summary: os.system exhausts file descriptors Initial Comment: this is a strange behavior that i could not make a concise test case for. i wrote a simple script to run several hundreds of jobs consecutively using os.system() call. on some occasions, especially when I use CTRL-C to break all of them to get out of the script (I didn't handle any signals...), i couldn't run the script again. the system gave a 'too many files open on the system' on a linux 2.4 (debian) system. suspecting that this might be due to os.system i wrote a simple run function that uses os.popen() instead. def run(cmd): a = os.popen(cmd) lines = a.readlines() return not a.close() and the problem never occured again. i can't tell why using os.system can cause that, i had never encountered this error on linux, to be honest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030388&group_id=5470 From noreply at sourceforge.net Sat Sep 18 19:54:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 19:54:22 2004 Subject: [ python-Bugs-1028697 ] Problem linking on windows using mingw32 and C++ Message-ID: Bugs item #1028697, was opened at 2004-09-15 13:28 Message generated for change (Comment added) made by devilwolf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steve Menard (devilwolf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem linking on windows using mingw32 and C++ Initial Comment: When create a python extension in C++ and using ming32 to compile it, distutil will try to use 'cc' as the linker. The problem is that the CCompiler.link() method will substitude the linker it has found in linker_exe or linker_so with the first part of compiler_cxx. (lines 175-176) So adding the following line to Mingw32Compiler, near line 296 compiler_cxx='g++ -mno-cygwin -O -Wall', Fixes it for me. Quickly looking at the CygwinCompiler indicates it would suffer from he same problem. ---------------------------------------------------------------------- >Comment By: Steve Menard (devilwolf) Date: 2004-09-18 13:54 Message: Logged In: YES user_id=423569 Indeed it does seem identical to http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165 thanks. ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2004-09-17 12:15 Message: Logged In: YES user_id=414645 Is this a duplicate of the following two bug reports? http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=877165 http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=832159 The first of those two was closed with a notice that the patch is in CVS; the second is still open. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028697&group_id=5470 From noreply at sourceforge.net Sun Sep 19 01:40:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 01:40:57 2004 Subject: [ python-Bugs-1030499 ] os.path.join() does not raise TypeError Message-ID: Bugs item #1030499, was opened at 2004-09-18 19:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030499&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pierre Fortin (pfortin) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join() does not raise TypeError Initial Comment: Within os and os.path, os.path.join() appears to be the only function which fails to indicate a TypeError. This was found inadvertently with: def foo(*args): ... return os.path.join(args) # note the missing "*" Calling the function with: foo('a','b') returns: ('a','b') Other os & os.path functions return TypeError in this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030499&group_id=5470 From noreply at sourceforge.net Sun Sep 19 06:22:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 06:22:35 2004 Subject: [ python-Bugs-1030557 ] PyMapping_Check crashes when argument is NULL Message-ID: Bugs item #1030557, was opened at 2004-09-19 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030557&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyMapping_Check crashes when argument is NULL Initial Comment: The function PyMapping_Check in Objects/abstract.c in Python 2.4a3 is int PyMapping_Check(PyObject *o) { if (PyInstance_Check(o)) return PyObject_HasAttrString(o, "__getitem__"); return o && o->ob_type->tp_as_mapping && o->ob_type->tp_as_mapping->mp_subscript && !(o->ob_type->tp_as_sequence && o->ob_type->tp_as_sequence->sq_slice); } where PyInstance_Check is #defined in Include/classobject.h as #define PyInstance_Check(op) ((op)->ob_type == &PyInstance_Type) Hence, if the argument o of PyMapping_Check is NULL, the function will crash. I first noticed this crash on Cygwin. The problem is that PyInstance_Check dereferences the argument o before the check for o==NULL is made in the return statement. In Python 2.3.4, PyMapping_Check was int PyMapping_Check(PyObject *o) { return o && o->ob_type->tp_as_mapping && o->ob_type->tp_as_mapping->mp_subscript; } which checks for o==NULL correctly. By the way, I am not sure if I am submitting this to the correct category. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030557&group_id=5470 From noreply at sourceforge.net Sun Sep 19 07:38:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 07:38:23 2004 Subject: [ python-Bugs-1030557 ] PyMapping_Check crashes when argument is NULL Message-ID: Bugs item #1030557, was opened at 2004-09-18 23:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030557&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Raymond Hettinger (rhettinger) Summary: PyMapping_Check crashes when argument is NULL Initial Comment: The function PyMapping_Check in Objects/abstract.c in Python 2.4a3 is int PyMapping_Check(PyObject *o) { if (PyInstance_Check(o)) return PyObject_HasAttrString(o, "__getitem__"); return o && o->ob_type->tp_as_mapping && o->ob_type->tp_as_mapping->mp_subscript && !(o->ob_type->tp_as_sequence && o->ob_type->tp_as_sequence->sq_slice); } where PyInstance_Check is #defined in Include/classobject.h as #define PyInstance_Check(op) ((op)->ob_type == &PyInstance_Type) Hence, if the argument o of PyMapping_Check is NULL, the function will crash. I first noticed this crash on Cygwin. The problem is that PyInstance_Check dereferences the argument o before the check for o==NULL is made in the return statement. In Python 2.3.4, PyMapping_Check was int PyMapping_Check(PyObject *o) { return o && o->ob_type->tp_as_mapping && o->ob_type->tp_as_mapping->mp_subscript; } which checks for o==NULL correctly. By the way, I am not sure if I am submitting this to the correct category. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030557&group_id=5470 From noreply at sourceforge.net Sun Sep 19 08:00:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 08:01:02 2004 Subject: [ python-Bugs-1030557 ] PyMapping_Check crashes when argument is NULL Message-ID: Bugs item #1030557, was opened at 2004-09-18 23:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030557&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Raymond Hettinger (rhettinger) Summary: PyMapping_Check crashes when argument is NULL Initial Comment: The function PyMapping_Check in Objects/abstract.c in Python 2.4a3 is int PyMapping_Check(PyObject *o) { if (PyInstance_Check(o)) return PyObject_HasAttrString(o, "__getitem__"); return o && o->ob_type->tp_as_mapping && o->ob_type->tp_as_mapping->mp_subscript && !(o->ob_type->tp_as_sequence && o->ob_type->tp_as_sequence->sq_slice); } where PyInstance_Check is #defined in Include/classobject.h as #define PyInstance_Check(op) ((op)->ob_type == &PyInstance_Type) Hence, if the argument o of PyMapping_Check is NULL, the function will crash. I first noticed this crash on Cygwin. The problem is that PyInstance_Check dereferences the argument o before the check for o==NULL is made in the return statement. In Python 2.3.4, PyMapping_Check was int PyMapping_Check(PyObject *o) { return o && o->ob_type->tp_as_mapping && o->ob_type->tp_as_mapping->mp_subscript; } which checks for o==NULL correctly. By the way, I am not sure if I am submitting this to the correct category. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-19 01:00 Message: Logged In: YES user_id=80475 It is not clear that this is actually a bug. Most of the PY???_Check functions expect a non-NULL object. The C API docs are silent on the subject. However, in the spirit of defensive programming, I added the early null checks back to PyMapping_Check and PySequence_Check. Fixed and checked in as: Objects/abstract.c 2.132 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030557&group_id=5470 From noreply at sourceforge.net Sun Sep 19 12:27:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 12:27:21 2004 Subject: [ python-Bugs-1030629 ] PyOS_InputHook broken Message-ID: Bugs item #1030629, was opened at 2004-09-19 19:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030629&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Nobody/Anonymous (nobody) Summary: PyOS_InputHook broken Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. In Python 2.3.4, calling PyOS_InputHook was handled by readline via rl_event_hook = PyOS_InputHook; ... p = readline(prompt); The readline library takes care of calling rl_event_hook (and hence PyOS_InputHook) ten times per second while Python idles at the call to readline(prompt). In Python 2.4a3, the call to readline is replaced by a call to readline_until_enter_or_signal. Here, the "select" function is used: has_input = select(fileno(rl_instream) + 1, &selectset, NULL, NULL, NULL); if(has_input > 0) { rl_callback_read_char(); } Now Python idles at "select", but PyOS_InputHook is not being called. Instead, PyOS_InputHook gets called via rl_event_hook at rl_callback_read_char. This means that PyOS_InputHook is called once for every character the user types, and is not called at all if the user is not typing something. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030629&group_id=5470 From noreply at sourceforge.net Wed Sep 15 06:20:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 17:27:13 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-14 21:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 10:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 03:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 10:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 09:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 03:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 12:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Sun Sep 19 20:35:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 20:35:32 2004 Subject: [ python-Bugs-1030629 ] PyOS_InputHook broken Message-ID: Bugs item #1030629, was opened at 2004-09-19 11:27 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030629&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Michael Hudson (mwh) Summary: PyOS_InputHook broken Initial Comment: PyOS_InputHook is a pointer to a function to be called periodically when Python is idle. It is used, for example, to get messages delivered to graphics windows. In Python 2.3.4, calling PyOS_InputHook was handled by readline via rl_event_hook = PyOS_InputHook; ... p = readline(prompt); The readline library takes care of calling rl_event_hook (and hence PyOS_InputHook) ten times per second while Python idles at the call to readline(prompt). In Python 2.4a3, the call to readline is replaced by a call to readline_until_enter_or_signal. Here, the "select" function is used: has_input = select(fileno(rl_instream) + 1, &selectset, NULL, NULL, NULL); if(has_input > 0) { rl_callback_read_char(); } Now Python idles at "select", but PyOS_InputHook is not being called. Instead, PyOS_InputHook gets called via rl_event_hook at rl_callback_read_char. This means that PyOS_InputHook is called once for every character the user types, and is not called at all if the user is not typing something. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-19 19:35 Message: Logged In: YES user_id=6656 Well, this is probably my fault. However, I'm about to go on holiday for a week and thinking about readline is definitely not part of my plans :-) Can you work up a patch for this? It shouldn't be terribly hard -- a non-NULL fifth argument to select seems in order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030629&group_id=5470 From noreply at sourceforge.net Mon Sep 20 02:34:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 02:34:50 2004 Subject: [ python-Bugs-1030941 ] Email message croaks the new email pkg parser Message-ID: Bugs item #1030941, was opened at 2004-09-19 19:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030941&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Email message croaks the new email pkg parser Initial Comment: The new parser for the email package croaks with an AssertionError on the attached email message. Here's the traceback: Traceback (most recent call last): File "/Users/skip/local/lib/python2.4/site-packages/ spambayes/mboxutils.py", line 129, in get_message msg = email.message_from_string(obj) File "/Users/skip/local/lib/python2.4/email/__init__.py", line 45, in message_from_string return Parser(_class, strict=strict).parsestr(s) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 67, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 56, in parse feedparser.feed(data) File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 145, in feed self._call_parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 149, in _call_parse self._parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 359, in _parsegen assert capturing_preamble Assigning to Barry on the outside chance that he'll have enough round tuits to fix this before the 2.4 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030941&group_id=5470 From noreply at sourceforge.net Mon Sep 20 13:10:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 13:10:54 2004 Subject: [ python-Bugs-1031148 ] tarfile: dirsize is not zero Message-ID: Bugs item #1031148, was opened at 2004-09-20 13:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031148&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile: dirsize is not zero Initial Comment: Tarring a directory (only a directory, not its contents) with the tar program results in user@host:~$ mkdir tmp user@host:~$ tar --no-recursion -cf sample.tar tmp/ user@host:~$ tar tfv sample.tar drwxr-xr-x user/user 0 2004-09-20 12:55:27 tmp/ Using the Python `tarfile' module, the result is user@host:~$ python ... >>> t = tarfile.open( 'sample.tar', 'w') >>> t.add( 'tmp', recursive = False) ... user@host:~$ tar tfv sample.tar drwxr-xr-x user/user 4096 2004-09-20 12:55:27 tmp/ But there are no 4096 Bytes in the tar file. If this is not actually a bug, I would like to propose it to be one. I may provide a solution to this at Bertram ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031148&group_id=5470 From noreply at sourceforge.net Mon Sep 20 17:37:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 17:37:47 2004 Subject: [ python-Feature Requests-1031288 ] Update unicodedata to version 4.0.1 Message-ID: Feature Requests item #1031288, was opened at 2004-09-20 17:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1031288&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Horn (ohorn) Assigned to: Nobody/Anonymous (nobody) Summary: Update unicodedata to version 4.0.1 Initial Comment: The unicodedata library (shipped with Python 2.3.4 and 2.4a3) is still version 3.2.0 albeit version 4.0.1 is available from unicode.org. Is it possible to update 4.0.1, at least for Python 2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1031288&group_id=5470 From noreply at sourceforge.net Mon Sep 20 21:52:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 21:52:28 2004 Subject: [ python-Bugs-1031480 ] decimal module inconsistent with integers and floats Message-ID: Bugs item #1031480, was opened at 2004-09-20 13:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: decimal module inconsistent with integers and floats Initial Comment: The Decimal class behaves differently from the builtin integer and float classes when performing modulus and integer division operations: >>> decimal.Decimal("14") % decimal.Decimal("10) Decimal("4") >>> decimal.Decimal("-14") % decimal.Decimal("10") Decimal("-4) >>> 14 % 10 4 >>> -14 % 10 6 Similar behavior occurs with negative numbers with the integer division operator //. Should these behave the same way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 From noreply at sourceforge.net Tue Sep 21 06:23:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 06:23:06 2004 Subject: [ python-Bugs-1031667 ] Fold tuples of constants into a single constant Message-ID: Bugs item #1031667, was opened at 2004-09-20 23:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Fold tuples of constants into a single constant Initial Comment: Folds tuples of constants into a single constant. Results in beautiful, fast bytecode: >>> from dis import dis >>> def f(): for x in ('a', 'b', 'c'): if x in (1, 2): return False return True >>> dis(f) 2 0 SETUP_LOOP 35 (to 38) 3 LOAD_CONST 6 (('a', 'b', 'c')) 6 GET_ITER >> 7 FOR_ITER 27 (to 37) 10 STORE_FAST 0 (x) 3 13 LOAD_FAST 0 (x) 16 LOAD_CONST 7 ((1, 2)) 19 COMPARE_OP 6 (in) 22 JUMP_IF_FALSE 8 (to 33) 25 POP_TOP 4 26 LOAD_GLOBAL 1 (False) 29 RETURN_VALUE 30 JUMP_ABSOLUTE 7 >> 33 POP_TOP 34 JUMP_ABSOLUTE 7 >> 37 POP_BLOCK 5 >> 38 LOAD_GLOBAL 2 (True) 41 RETURN_VALUE ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 From noreply at sourceforge.net Tue Sep 21 06:55:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 06:56:03 2004 Subject: [ python-Bugs-1031480 ] decimal module inconsistent with integers and floats Message-ID: Bugs item #1031480, was opened at 2004-09-20 14:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Tim Peters (tim_one) Summary: decimal module inconsistent with integers and floats Initial Comment: The Decimal class behaves differently from the builtin integer and float classes when performing modulus and integer division operations: >>> decimal.Decimal("14") % decimal.Decimal("10) Decimal("4") >>> decimal.Decimal("-14") % decimal.Decimal("10") Decimal("-4) >>> 14 % 10 4 >>> -14 % 10 6 Similar behavior occurs with negative numbers with the integer division operator //. Should these behave the same way? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-20 23:55 Message: Logged In: YES user_id=80475 Tim, what do you think? Should the python operators behave the same across numeric types while leaving the direct spec API intact or would it be too suprising to have the operators functioning in a way not contemplated by the spec. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 From noreply at sourceforge.net Tue Sep 21 07:12:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 07:12:22 2004 Subject: [ python-Bugs-1030125 ] rfc822 __iter__ problem Message-ID: Bugs item #1030125, was opened at 2004-09-17 17:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 Category: Python Library >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822 __iter__ problem Initial Comment: >>> from urllib2 import urlopen >>> a = urlopen('http://www.voidspace.org.uk') >>> i = a.info() >>> for entry in i: print entry Traceback (most recent call last): File "", line 1, in -toplevel- for entry in i: print entry File "D:\PYTHON23\lib\rfc822.py", line 390, in __getitem__ return self.dict[name.lower()] AttributeError: 'int' object has no attribute 'lower' Iterating over an rfc822 message (above done from urllib2) causes an exception. Could be fixed by returning an iter(self.dict) from the __iter__ method. This bug looks similar to bug 1017329. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 00:12 Message: Logged In: YES user_id=80475 This seems like a reasonable feature request. Though I don't know if it makes sense to improve a module that is slated for deprecation per PEP 4. If accepted, I would subclass from UserDict.DictMixin to complete the dictionary iterface including __iter__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 From noreply at sourceforge.net Tue Sep 21 08:03:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 08:03:08 2004 Subject: [ python-Bugs-1030125 ] rfc822 __iter__ problem Message-ID: Bugs item #1030125, was opened at 2004-09-17 17:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822 __iter__ problem Initial Comment: >>> from urllib2 import urlopen >>> a = urlopen('http://www.voidspace.org.uk') >>> i = a.info() >>> for entry in i: print entry Traceback (most recent call last): File "", line 1, in -toplevel- for entry in i: print entry File "D:\PYTHON23\lib\rfc822.py", line 390, in __getitem__ return self.dict[name.lower()] AttributeError: 'int' object has no attribute 'lower' Iterating over an rfc822 message (above done from urllib2) causes an exception. Could be fixed by returning an iter(self.dict) from the __iter__ method. This bug looks similar to bug 1017329. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 01:03 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 00:12 Message: Logged In: YES user_id=80475 This seems like a reasonable feature request. Though I don't know if it makes sense to improve a module that is slated for deprecation per PEP 4. If accepted, I would subclass from UserDict.DictMixin to complete the dictionary iterface including __iter__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 From noreply at sourceforge.net Tue Sep 21 15:44:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 15:44:24 2004 Subject: [ python-Bugs-1031897 ] Conflicting descriptions of application order of decorators Message-ID: Bugs item #1031897, was opened at 2004-09-21 14:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hamish Lawson (hamishlawson) Assigned to: Nobody/Anonymous (nobody) Summary: Conflicting descriptions of application order of decorators Initial Comment: The explanation of decorators in "What's new in Python 2.4" has the application order opposite to that stated in the Reference Manual. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 From noreply at sourceforge.net Tue Sep 21 17:16:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 17:16:23 2004 Subject: [ python-Bugs-1031897 ] Conflicting descriptions of application order of decorators Message-ID: Bugs item #1031897, was opened at 2004-09-21 15:44 Message generated for change (Comment added) made by pfremy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hamish Lawson (hamishlawson) Assigned to: Nobody/Anonymous (nobody) Summary: Conflicting descriptions of application order of decorators Initial Comment: The explanation of decorators in "What's new in Python 2.4" has the application order opposite to that stated in the Reference Manual. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2004-09-21 17:16 Message: Logged In: YES user_id=233844 And the PEP 318 is in conflict with the "What's new in Python 2.4" but in accordance with the manual. So it is very probably a problem in the what'snew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 From noreply at sourceforge.net Tue Sep 21 17:21:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 17:21:39 2004 Subject: [ python-Bugs-1031897 ] Conflicting descriptions of application order of decorators Message-ID: Bugs item #1031897, was opened at 2004-09-21 08:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hamish Lawson (hamishlawson) >Assigned to: A.M. Kuchling (akuchling) Summary: Conflicting descriptions of application order of decorators Initial Comment: The explanation of decorators in "What's new in Python 2.4" has the application order opposite to that stated in the Reference Manual. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2004-09-21 10:16 Message: Logged In: YES user_id=233844 And the PEP 318 is in conflict with the "What's new in Python 2.4" but in accordance with the manual. So it is very probably a problem in the what'snew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 From noreply at sourceforge.net Tue Sep 21 18:45:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 18:45:21 2004 Subject: [ python-Bugs-1028334 ] get_installer_filename Message-ID: Bugs item #1028334, was opened at 2004-09-15 05:50 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028334&group_id=5470 Category: Distutils Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: bingo (ww_dragon) >Assigned to: Thomas Heller (theller) Summary: get_installer_filename Initial Comment: \Lib\distutils\command\bdist_wininst.py function get_installer_filename must return installer_name; ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-09-21 18:45 Message: Logged In: YES user_id=11105 I *think* this is fixed in 2.4a3 - at least it is already fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028334&group_id=5470 From noreply at sourceforge.net Tue Sep 21 21:03:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 21:03:47 2004 Subject: [ python-Bugs-1031148 ] tarfile: dirsize is not zero Message-ID: Bugs item #1031148, was opened at 2004-09-20 13:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031148&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile: dirsize is not zero Initial Comment: Tarring a directory (only a directory, not its contents) with the tar program results in user@host:~$ mkdir tmp user@host:~$ tar --no-recursion -cf sample.tar tmp/ user@host:~$ tar tfv sample.tar drwxr-xr-x user/user 0 2004-09-20 12:55:27 tmp/ Using the Python `tarfile' module, the result is user@host:~$ python ... >>> t = tarfile.open( 'sample.tar', 'w') >>> t.add( 'tmp', recursive = False) ... user@host:~$ tar tfv sample.tar drwxr-xr-x user/user 4096 2004-09-20 12:55:27 tmp/ But there are no 4096 Bytes in the tar file. If this is not actually a bug, I would like to propose it to be one. I may provide a solution to this at Bertram ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-21 21:03 Message: Logged In: YES user_id=21627 This was fixed in tarfile.py 1.16 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031148&group_id=5470 From noreply at sourceforge.net Tue Sep 21 21:08:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 21:09:05 2004 Subject: [ python-Bugs-1031667 ] Fold tuples of constants into a single constant Message-ID: Bugs item #1031667, was opened at 2004-09-21 06:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Fold tuples of constants into a single constant Initial Comment: Folds tuples of constants into a single constant. Results in beautiful, fast bytecode: >>> from dis import dis >>> def f(): for x in ('a', 'b', 'c'): if x in (1, 2): return False return True >>> dis(f) 2 0 SETUP_LOOP 35 (to 38) 3 LOAD_CONST 6 (('a', 'b', 'c')) 6 GET_ITER >> 7 FOR_ITER 27 (to 37) 10 STORE_FAST 0 (x) 3 13 LOAD_FAST 0 (x) 16 LOAD_CONST 7 ((1, 2)) 19 COMPARE_OP 6 (in) 22 JUMP_IF_FALSE 8 (to 33) 25 POP_TOP 4 26 LOAD_GLOBAL 1 (False) 29 RETURN_VALUE 30 JUMP_ABSOLUTE 7 >> 33 POP_TOP 34 JUMP_ABSOLUTE 7 >> 37 POP_BLOCK 5 >> 38 LOAD_GLOBAL 2 (True) 41 RETURN_VALUE ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-21 21:08 Message: Logged In: YES user_id=21627 There is a change in semantics, of course: the program def f(): return 1,2 print f() is f() used to print False, now prints True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 From noreply at sourceforge.net Tue Sep 21 21:14:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 21:14:11 2004 Subject: [ python-Bugs-1030388 ] os.system exhausts file descriptors Message-ID: Bugs item #1030388, was opened at 2004-09-18 19:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030388&group_id=5470 Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Eray Ozkural (exa) Assigned to: Nobody/Anonymous (nobody) Summary: os.system exhausts file descriptors Initial Comment: this is a strange behavior that i could not make a concise test case for. i wrote a simple script to run several hundreds of jobs consecutively using os.system() call. on some occasions, especially when I use CTRL-C to break all of them to get out of the script (I didn't handle any signals...), i couldn't run the script again. the system gave a 'too many files open on the system' on a linux 2.4 (debian) system. suspecting that this might be due to os.system i wrote a simple run function that uses os.popen() instead. def run(cmd): a = os.popen(cmd) lines = a.readlines() return not a.close() and the problem never occured again. i can't tell why using os.system can cause that, i had never encountered this error on linux, to be honest. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-21 21:14 Message: Logged In: YES user_id=21627 This sounds like a bug in your C library, or an unrelated bug in the programs you start, or in your Python application. Python's os.system is just a thin wrapper around system(3). So I'm closing this as third-party unless there is some stronger evidence that there actually is a problem with Python here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030388&group_id=5470 From noreply at sourceforge.net Tue Sep 21 21:29:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 21:29:32 2004 Subject: [ python-Bugs-1031667 ] Fold tuples of constants into a single constant Message-ID: Bugs item #1031667, was opened at 2004-09-21 00:23 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Fold tuples of constants into a single constant Initial Comment: Folds tuples of constants into a single constant. Results in beautiful, fast bytecode: >>> from dis import dis >>> def f(): for x in ('a', 'b', 'c'): if x in (1, 2): return False return True >>> dis(f) 2 0 SETUP_LOOP 35 (to 38) 3 LOAD_CONST 6 (('a', 'b', 'c')) 6 GET_ITER >> 7 FOR_ITER 27 (to 37) 10 STORE_FAST 0 (x) 3 13 LOAD_FAST 0 (x) 16 LOAD_CONST 7 ((1, 2)) 19 COMPARE_OP 6 (in) 22 JUMP_IF_FALSE 8 (to 33) 25 POP_TOP 4 26 LOAD_GLOBAL 1 (False) 29 RETURN_VALUE 30 JUMP_ABSOLUTE 7 >> 33 POP_TOP 34 JUMP_ABSOLUTE 7 >> 37 POP_BLOCK 5 >> 38 LOAD_GLOBAL 2 (True) 41 RETURN_VALUE ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-21 15:29 Message: Logged In: YES user_id=31435 That's OK. The language reference manual has always been careful to say that an expression returning an immutable object may or may not return a pre-existing object. "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed" So, e.g., had your function been def f(): return () it was already true, under CPython, that f() is f(). No correct Python program could rely on that, though; neither on that only the empty tuple has been shared until now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-21 15:08 Message: Logged In: YES user_id=21627 There is a change in semantics, of course: the program def f(): return 1,2 print f() is f() used to print False, now prints True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 From noreply at sourceforge.net Wed Sep 22 01:20:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 01:20:30 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by peterkleiweg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-22 01:20 Message: Logged In: YES user_id=1118097 I can only find a change in file lib-tk/tkMessageBox.py. Is this a true fix for expected behaviour of Tk? Or is this just a workaround for something murky deeper in Tk that may or may not be a bug? Is there perhaps a bug in the new behaviour of Tkinter that gets activated through the variable 'Tkinter.wantobjects'? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:06 Message: Logged In: YES user_id=21627 This is now fixed in tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 I'd be still curious at what point Tcl converts the string "yes" into a boolean, and why this happens only on some installations. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-09 10:43 Message: Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 23:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 14:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 13:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 12:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Wed Sep 22 03:26:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 03:26:37 2004 Subject: [ python-Bugs-1031480 ] decimal module inconsistent with integers and floats Message-ID: Bugs item #1031480, was opened at 2004-09-20 15:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: decimal module inconsistent with integers and floats Initial Comment: The Decimal class behaves differently from the builtin integer and float classes when performing modulus and integer division operations: >>> decimal.Decimal("14") % decimal.Decimal("10) Decimal("4") >>> decimal.Decimal("-14") % decimal.Decimal("10") Decimal("-4) >>> 14 % 10 4 >>> -14 % 10 6 Similar behavior occurs with negative numbers with the integer division operator //. Should these behave the same way? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-21 21:26 Message: Logged In: YES user_id=31435 Alas, there's no good solution to this. Python's definition of mod doesn't make sense for floats. Consider, e.g., (-1e-100) % 1e100 math.fmod() applied to this returns (the exactly correct) -1e- 100, but Python's float.__mod__ returns the absurd (on more than one count) 1e100. math.fmod() can always compute an exactly correct result, but float.__mod__ cannot. As the example shows, float.__mod__(x, y) can't even guarantee abs (x % y) < abs(y) for non-zero y (but math.fmod() can). OTOH, math.fmod's "sign of the first argument" rule is silly compared to Python's "sign of the second argument" rule for integers. It's a mistake to believe that one definition of mod "should" work across numeric types. Since Decimal is in fact a floating type, I'd prefer to stick to the IBM spec's definition, which (unlike Python's) makes sense for floats. That's not a good solution; but neither would be extending the IBM spec to introduce a broken-for-floats meaning just because Python's float.__mod__ is broken. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 00:55 Message: Logged In: YES user_id=80475 Tim, what do you think? Should the python operators behave the same across numeric types while leaving the direct spec API intact or would it be too suprising to have the operators functioning in a way not contemplated by the spec. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 From noreply at sourceforge.net Wed Sep 22 04:43:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 04:43:54 2004 Subject: [ python-Bugs-1031480 ] decimal module inconsistent with integers and floats Message-ID: Bugs item #1031480, was opened at 2004-09-20 14:52 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Tim Peters (tim_one) Summary: decimal module inconsistent with integers and floats Initial Comment: The Decimal class behaves differently from the builtin integer and float classes when performing modulus and integer division operations: >>> decimal.Decimal("14") % decimal.Decimal("10) Decimal("4") >>> decimal.Decimal("-14") % decimal.Decimal("10") Decimal("-4) >>> 14 % 10 4 >>> -14 % 10 6 Similar behavior occurs with negative numbers with the integer division operator //. Should these behave the same way? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-21 20:26 Message: Logged In: YES user_id=31435 Alas, there's no good solution to this. Python's definition of mod doesn't make sense for floats. Consider, e.g., (-1e-100) % 1e100 math.fmod() applied to this returns (the exactly correct) -1e- 100, but Python's float.__mod__ returns the absurd (on more than one count) 1e100. math.fmod() can always compute an exactly correct result, but float.__mod__ cannot. As the example shows, float.__mod__(x, y) can't even guarantee abs (x % y) < abs(y) for non-zero y (but math.fmod() can). OTOH, math.fmod's "sign of the first argument" rule is silly compared to Python's "sign of the second argument" rule for integers. It's a mistake to believe that one definition of mod "should" work across numeric types. Since Decimal is in fact a floating type, I'd prefer to stick to the IBM spec's definition, which (unlike Python's) makes sense for floats. That's not a good solution; but neither would be extending the IBM spec to introduce a broken-for-floats meaning just because Python's float.__mod__ is broken. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-20 23:55 Message: Logged In: YES user_id=80475 Tim, what do you think? Should the python operators behave the same across numeric types while leaving the direct spec API intact or would it be too suprising to have the operators functioning in a way not contemplated by the spec. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470 From noreply at sourceforge.net Wed Sep 22 04:49:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 04:49:13 2004 Subject: [ python-Bugs-1018315 ] __new__ not defined? Message-ID: Bugs item #1018315, was opened at 2004-08-29 06:59 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: __new__ not defined? Initial Comment: I can't find __new__ in the index for either the Language Reference Manual or Library Reference Manual. Poking around I did find it mentioned in ext/newtypes.tex, but without any details. I'd submit something, but I don't know at this point how to use it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-22 12:49 Message: Logged In: YES user_id=1038590 I had the same problem when trying to convert Decimal to use __new__ instead of __init__. The only info I could find was http://www.python.org/2.2.3/descrintro.html. Which actually does a very good job of explaining how new-style classes work. The only problem is that it is on the website, but NOT referenced in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470 From noreply at sourceforge.net Wed Sep 22 08:29:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 08:29:52 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-22 08:29 Message: Logged In: YES user_id=21627 I don't see a bug in the integration of Tcl objects into Python. Do you? ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-22 01:20 Message: Logged In: YES user_id=1118097 I can only find a change in file lib-tk/tkMessageBox.py. Is this a true fix for expected behaviour of Tk? Or is this just a workaround for something murky deeper in Tk that may or may not be a bug? Is there perhaps a bug in the new behaviour of Tkinter that gets activated through the variable 'Tkinter.wantobjects'? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:06 Message: Logged In: YES user_id=21627 This is now fixed in tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 I'd be still curious at what point Tcl converts the string "yes" into a boolean, and why this happens only on some installations. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-09 10:43 Message: Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 23:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 14:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 13:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 12:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Wed Sep 22 09:18:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 09:18:39 2004 Subject: [ python-Bugs-1032395 ] idle -n crashes Message-ID: Bugs item #1032395, was opened at 2004-09-22 09:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032395&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: idle -n crashes Initial Comment: [forwarded from http://bugs.debian.org/272796] $ idle -n (Tk window appears) (Some traceback in red?) (Tk window disappears) screenshot appended. bug submitter writes that idle -n in Windows works (not sure, if he tested 2.3.x or 2.4). idle from 2.4a0 works ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032395&group_id=5470 From noreply at sourceforge.net Wed Sep 22 12:52:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 12:53:04 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 15:18 Message generated for change (Comment added) made by jiba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-22 10:52 Message: Logged In: YES user_id=591223 peterkleiweg : it's a workaround. It's better than nothing and it fixes the bug, but i fear the real bug is still somewhere hidden in _tkinter.c... i've searched for it, but i didn't find it though :-( ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-22 06:29 Message: Logged In: YES user_id=21627 I don't see a bug in the integration of Tcl objects into Python. Do you? ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-21 23:20 Message: Logged In: YES user_id=1118097 I can only find a change in file lib-tk/tkMessageBox.py. Is this a true fix for expected behaviour of Tk? Or is this just a workaround for something murky deeper in Tk that may or may not be a bug? Is there perhaps a bug in the new behaviour of Tkinter that gets activated through the variable 'Tkinter.wantobjects'? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 16:06 Message: Logged In: YES user_id=21627 This is now fixed in tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 I'd be still curious at what point Tcl converts the string "yes" into a boolean, and why this happens only on some installations. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-09 08:43 Message: Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 21:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 12:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 11:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 10:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-19 22:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 15:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Wed Sep 22 15:00:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 15:00:28 2004 Subject: [ python-Bugs-1032615 ] Odd behavior with unicode.translate on OSX. Message-ID: Bugs item #1032615, was opened at 2004-09-22 09:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 Category: Unicode Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: M.-A. Lemburg (lemburg) Summary: Odd behavior with unicode.translate on OSX. Initial Comment: d = {ord('f'): 'eff '} for i in range(100): ....s = u'f' * i ....print i ....s.translate(d) On my Panther laptop, that fails at i=25 with a MemoryError: *** malloc: vm_allocate(size=1677725696) failed (error code=3) *** malloc[2346]: error: Can't allocate region Traceback (most recent call last): ..File "", line 4, in ? MemoryError It works fine on the Linux and BSD boxes I was able to test on, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 From noreply at sourceforge.net Wed Sep 22 15:10:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 15:10:27 2004 Subject: [ python-Bugs-1032615 ] Odd behavior with unicode.translate on OSX. Message-ID: Bugs item #1032615, was opened at 2004-09-22 09:00 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 Category: Unicode Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: M.-A. Lemburg (lemburg) Summary: Odd behavior with unicode.translate on OSX. Initial Comment: d = {ord('f'): 'eff '} for i in range(100): ....s = u'f' * i ....print i ....s.translate(d) On my Panther laptop, that fails at i=25 with a MemoryError: *** malloc: vm_allocate(size=1677725696) failed (error code=3) *** malloc[2346]: error: Can't allocate region Traceback (most recent call last): ..File "", line 4, in ? MemoryError It works fine on the Linux and BSD boxes I was able to test on, though. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2004-09-22 09:10 Message: Logged In: YES user_id=99508 Oops, that 'eff ' should be u'eff ', obviously. Sorry about that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 From noreply at sourceforge.net Wed Sep 22 15:43:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 15:43:50 2004 Subject: [ python-Bugs-932563 ] logging: need a way to discard Logger objects Message-ID: Bugs item #932563, was opened at 2004-04-09 21:51 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932563&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None >Priority: 7 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: logging: need a way to discard Logger objects Initial Comment: There needs to be a way to tell the logging package that an application is done with a particular logger object. This is important for long-running processes that want to use a logger to represent a related set of activities over a relatively short period of time (compared to the life of the process). This is useful to allow creating per-connection loggers for internet servers, for example. Using a connection-specific logger allows the application to provide an identifier for the session that can be automatically included in the logs without having the application encode it into each message (a far more error prone approach). ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-09-22 13:43 Message: Logged In: YES user_id=308438 Hi Fred, Any update on this? If you haven't the time (which I quite understand), please post the code which does the Right Thing (or mail it to me) without an explanation, and I'll try to understand it. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-01 03:53 Message: Logged In: YES user_id=3066 Vinay: I don't think that will work. Another issue that crops up once I start looking into the Logger class is that findCaller() won't do (what I think is) the Right Thing when wrappers and subclasses are involved. After reviewing my application, I think the only thing the application really needs to control is the creation of the record objects, but that has to happen on the wrapper, or there's no way to get the necessary information into the record (without seriously performing surgery on the underlying logger). I think I've come up with a base class that does the Right Thing, but I need to write up an explanation of why it works the way it does. It's not massively mysterious, but does end up dealing with more than I really like worrying about. I don't have any more time for this tonight, but will write up what I have and post it here in the next few days. It shouldn't be hard to refactor what's in logging.Logger and my base class to share most of the code. Having the base class in the logging package would avoid having to use a separate findCaller() implementation. Boosting the priority to make sure this stays on my radar. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-06-29 22:10 Message: Logged In: YES user_id=308438 I just had a further thought: is the approach below any good to you? Apart from not being able to use the root logger, it seems to meet your need. import logging class MyLogger(logging.Logger): def makeRecord(self, name, level, fn, lno, msg, args, exc_info): record = logging.Logger.makeRecord(self, name, level, fn, lno, msg, args, exc_info) record.magicnumber = 0xDECAFBAD # special number return record logging._loggerClass = MyLogger h = logging.StreamHandler() logger = logging.getLogger("mylogger") h.setFormatter(logging.Formatter("%(asctime)s %(levelname) s %(magicnumber)X %(message)s")) logger.addHandler(h) logger.warn("There's a custom attribute in my message!") ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-06-24 15:28 Message: Logged In: YES user_id=308438 Suppose I add a callable "recordMaker" to logging, and modify makeRecord() to call it with logger + the args passed to makeRecord(). If it's necessary to add extra attrs to the LogRecord, this can be done by replacing recordMaker with your own callable. Seems less icky - what do you think? If you think it'll fly, are there any other args you think I need to pass into the callable? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-06-24 14:06 Message: Logged In: YES user_id=3066 I've attached a file showing the class I came up with. I don't consider this to be a good wrapper, just what worked. I think one of the problems is that what I really want to override is the makeRecord() method, not the logging methods themselves. There's too much logic in those dealing with the disabling and level filtering that I don't want to duplicate, but as soon as I pass the calls on to the underlying logger, I can no longer change the makeRecord(). It would be possible to inject a new makeRecord() while my methods are active (in my definition for log() in the sample), and restore the original in a finally clause, but that feels... icky. The advantage of overriding makeRecord() is that formatter can deal with with how the additional information is added to the log because more information is made available on the record. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-06-24 10:58 Message: Logged In: YES user_id=308438 How about if I add a LoggerAdapter class which takes a logger in the __init__ and has logging methods debug(), info() etc. [and including _log()] which delegate to the underlying logger? Then you could subclass the Adapter and just override the methods you needed. Would that fit the bill? Of course the package can use a Logger-derived class, but this would apply to all loggers where the LoggerAdapter could be used for just some of the loggers in a system. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-06-24 04:13 Message: Logged In: YES user_id=3066 Looking at this again, after adjusting the application I have that used the connection-specific loggers, I decided that a different approach better solves the problem. What you've shown requires exactly what I wanted to avoid: having to make a gesture at each logging call (to transform the message). Instead of doing this, I ended up writing a wrapper for the logger objects that implement the methods log(), debug(), info(), warn(), warning(), error(), exception(), critical(), and fatal(). These methods each transform the message before calling the underlying logger. It would be really nice to have something like this that isolates the final call to Logger._log() so specific implementations can simply override _log() (or some other helper routine that gets all the info) and maybe the __init__(). I don't think that's completely necessary, but would probably make it a lot easier to implement this pattern. There's probably some useful documentation improvements that could be made to help people avoid the issue of leaking loggers. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-06-10 16:50 Message: Logged In: YES user_id=3066 Sorry for the delay in following up. I'll re-visit the software where I wanted this to see how it'll work out in practice. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-09 16:01 Message: Logged In: YES user_id=31435 Assigned to Fred, because Vinay wants his input (in general, a bug should be assigned to the next person who needs to "do something" about it, and that can change over time). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-06-09 09:28 Message: Logged In: YES user_id=308438 Fred, any more thoughts on this? Thanks, Vinay ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2004-05-08 19:28 Message: Logged In: YES user_id=308438 The problem with disposing of Logger objects programmatically is that you don't know who is referencing them. How about the following approach? I'm making no assumptions about the actual connection classes used; if you need to make it even less error prone, you can create delegating methods in the server class which do the appropriate wrapping. class ConnectionWrapper: def __init__(self, conn): self.conn = conn def message(self, msg): return "[connection: %s]: %s" % (self.conn, msg) and then use this like so... class Server: def get_connection(self, request): # return the connection for this request def handle_request(self, request): conn = self.get_connection(request) # we use a cache of connection wrappers if conn in self.conn_cache: cw = self.conn_cache[conn] else: cw = ConnectionWrapper(conn) self.conn_cache[conn] = cw #process request, and if events need to be logged, you can e.g. logger.debug(cw.message("Network packet truncated at %d bytes"), n) #The logged message will contain the connection ID ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=932563&group_id=5470 From noreply at sourceforge.net Wed Sep 22 18:35:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 18:35:50 2004 Subject: [ python-Bugs-1030125 ] rfc822 __iter__ problem Message-ID: Bugs item #1030125, was opened at 2004-09-17 18:10 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822 __iter__ problem Initial Comment: >>> from urllib2 import urlopen >>> a = urlopen('http://www.voidspace.org.uk') >>> i = a.info() >>> for entry in i: print entry Traceback (most recent call last): File "", line 1, in -toplevel- for entry in i: print entry File "D:\PYTHON23\lib\rfc822.py", line 390, in __getitem__ return self.dict[name.lower()] AttributeError: 'int' object has no attribute 'lower' Iterating over an rfc822 message (above done from urllib2) causes an exception. Could be fixed by returning an iter(self.dict) from the __iter__ method. This bug looks similar to bug 1017329. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-22 12:35 Message: Logged In: YES user_id=12800 It doesn't seem right to me to inherit from UserDict since a Message is definitely /not/ a dictionary. E.g. it may have multiple occurances of the same header. I'm fine with adding an __iter__ if you want because even though rfc822 is slated for deprecation, unfortunately there are still parts of the stdlib that haven't been rewritten to use the email package. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 02:03 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 01:12 Message: Logged In: YES user_id=80475 This seems like a reasonable feature request. Though I don't know if it makes sense to improve a module that is slated for deprecation per PEP 4. If accepted, I would subclass from UserDict.DictMixin to complete the dictionary iterface including __iter__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 From noreply at sourceforge.net Wed Sep 22 19:23:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 19:23:08 2004 Subject: [ python-Bugs-1032615 ] Odd behavior with unicode.translate on OSX. Message-ID: Bugs item #1032615, was opened at 2004-09-22 15:00 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 Category: Unicode Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: M.-A. Lemburg (lemburg) Summary: Odd behavior with unicode.translate on OSX. Initial Comment: d = {ord('f'): 'eff '} for i in range(100): ....s = u'f' * i ....print i ....s.translate(d) On my Panther laptop, that fails at i=25 with a MemoryError: *** malloc: vm_allocate(size=1677725696) failed (error code=3) *** malloc[2346]: error: Can't allocate region Traceback (most recent call last): ..File "", line 4, in ? MemoryError It works fine on the Linux and BSD boxes I was able to test on, though. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-09-22 19:23 Message: Logged In: YES user_id=89016 This is probably a duplicate of bug 828737 ("unicode translate leaks memory"), which should be fixed in the current version 2.3.4. Which version of Python are you using? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2004-09-22 15:10 Message: Logged In: YES user_id=99508 Oops, that 'eff ' should be u'eff ', obviously. Sorry about that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 From noreply at sourceforge.net Wed Sep 22 19:24:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 19:24:32 2004 Subject: [ python-Bugs-1030125 ] rfc822 __iter__ problem Message-ID: Bugs item #1030125, was opened at 2004-09-17 17:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822 __iter__ problem Initial Comment: >>> from urllib2 import urlopen >>> a = urlopen('http://www.voidspace.org.uk') >>> i = a.info() >>> for entry in i: print entry Traceback (most recent call last): File "", line 1, in -toplevel- for entry in i: print entry File "D:\PYTHON23\lib\rfc822.py", line 390, in __getitem__ return self.dict[name.lower()] AttributeError: 'int' object has no attribute 'lower' Iterating over an rfc822 message (above done from urllib2) causes an exception. Could be fixed by returning an iter(self.dict) from the __iter__ method. This bug looks similar to bug 1017329. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-22 12:24 Message: Logged In: YES user_id=80475 Fixed. See Lib/rfc822.py 1.78. Added only the __iter__ method. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-22 11:35 Message: Logged In: YES user_id=12800 It doesn't seem right to me to inherit from UserDict since a Message is definitely /not/ a dictionary. E.g. it may have multiple occurances of the same header. I'm fine with adding an __iter__ if you want because even though rfc822 is slated for deprecation, unfortunately there are still parts of the stdlib that haven't been rewritten to use the email package. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 01:03 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-21 00:12 Message: Logged In: YES user_id=80475 This seems like a reasonable feature request. Though I don't know if it makes sense to improve a module that is slated for deprecation per PEP 4. If accepted, I would subclass from UserDict.DictMixin to complete the dictionary iterface including __iter__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030125&group_id=5470 From noreply at sourceforge.net Wed Sep 22 20:28:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 20:29:01 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-22 20:28 Message: Logged In: YES user_id=21627 I'm certain the bug is not in _tkinter. If _tkinter says it is a boolean (True or False), then only because Tcl told it is a boolean. Tcl tells so if somebody inside Tcl tried to convert the string to a boolean, and, unfortunately, "yes", "true", and a number of other string values all convert to logical true, and "no", "false", and some others convert to logical false. The remaining question is why that conversion is invoked for the dialogs (when the strings clearly are not meant as boolean values); this can be best found out by setting a breakpoint on Tcl_GetBoolean, SetBooleanFromAny, and possibly the 'y' case of GetLexeme. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-22 12:52 Message: Logged In: YES user_id=591223 peterkleiweg : it's a workaround. It's better than nothing and it fixes the bug, but i fear the real bug is still somewhere hidden in _tkinter.c... i've searched for it, but i didn't find it though :-( ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-22 08:29 Message: Logged In: YES user_id=21627 I don't see a bug in the integration of Tcl objects into Python. Do you? ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-22 01:20 Message: Logged In: YES user_id=1118097 I can only find a change in file lib-tk/tkMessageBox.py. Is this a true fix for expected behaviour of Tk? Or is this just a workaround for something murky deeper in Tk that may or may not be a bug? Is there perhaps a bug in the new behaviour of Tkinter that gets activated through the variable 'Tkinter.wantobjects'? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:06 Message: Logged In: YES user_id=21627 This is now fixed in tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 I'd be still curious at what point Tcl converts the string "yes" into a boolean, and why this happens only on some installations. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-09-09 10:43 Message: Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 23:39 Message: Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 ---------------------------------------------------------------------- Comment By: Peter Kleiweg (peterkleiweg) Date: 2004-09-08 14:37 Message: Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 13:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 12:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Wed Sep 22 20:44:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 20:44:53 2004 Subject: [ python-Bugs-1031667 ] Fold tuples of constants into a single constant Message-ID: Bugs item #1031667, was opened at 2004-09-20 23:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Fold tuples of constants into a single constant Initial Comment: Folds tuples of constants into a single constant. Results in beautiful, fast bytecode: >>> from dis import dis >>> def f(): for x in ('a', 'b', 'c'): if x in (1, 2): return False return True >>> dis(f) 2 0 SETUP_LOOP 35 (to 38) 3 LOAD_CONST 6 (('a', 'b', 'c')) 6 GET_ITER >> 7 FOR_ITER 27 (to 37) 10 STORE_FAST 0 (x) 3 13 LOAD_FAST 0 (x) 16 LOAD_CONST 7 ((1, 2)) 19 COMPARE_OP 6 (in) 22 JUMP_IF_FALSE 8 (to 33) 25 POP_TOP 4 26 LOAD_GLOBAL 1 (False) 29 RETURN_VALUE 30 JUMP_ABSOLUTE 7 >> 33 POP_TOP 34 JUMP_ABSOLUTE 7 >> 37 POP_BLOCK 5 >> 38 LOAD_GLOBAL 2 (True) 41 RETURN_VALUE ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-22 13:44 Message: Logged In: YES user_id=80475 See Python/compile.c 2.327 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-21 14:29 Message: Logged In: YES user_id=31435 That's OK. The language reference manual has always been careful to say that an expression returning an immutable object may or may not return a pre-existing object. "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed" So, e.g., had your function been def f(): return () it was already true, under CPython, that f() is f(). No correct Python program could rely on that, though; neither on that only the empty tuple has been shared until now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-21 14:08 Message: Logged In: YES user_id=21627 There is a change in semantics, of course: the program def f(): return 1,2 print f() is f() used to print False, now prints True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031667&group_id=5470 From noreply at sourceforge.net Wed Sep 22 21:21:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 21:21:06 2004 Subject: [ python-Bugs-1032875 ] ftplib has incomplete transfer when sending files in Windows Message-ID: Bugs item #1032875, was opened at 2004-09-22 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032875&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ed Sanville (infinity314) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib has incomplete transfer when sending files in Windows Initial Comment: I wrote the following short script: from ftplib import FTP ftp=FTP('ftp.edsanville.us', username, password) print ftp.getwelcome() print ftp.storbinary('stor test.xls', file('test.xls', 'r')) ftp.quit() It transfers the entire file under Red Hat Linux 9, but under Windows XP, it only transfers a couple kilobytes at most. Using a hex editor, I found that the first 5 or 6 bytes of the file are OK on the remote side after transfer, but the rest of the file is totally wrong. I'm at a loss, it doesn't make any sense. Please, somebody tell me I'm not insane. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032875&group_id=5470 From noreply at sourceforge.net Wed Sep 22 22:50:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 22:50:52 2004 Subject: [ python-Bugs-1032960 ] Confusing description of strict option for email.Parser Message-ID: Bugs item #1032960, was opened at 2004-09-23 06:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032960&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing description of strict option for email.Parser Initial Comment: The docs at http://www.python.org/dev/doc/devel/lib/node534.html say: "Normally, when things like MIME terminating boundaries are missing, or when messages contain other formatting problems, the Parser will raise a MessageParseError. However, when lax parsing is enabled, the Parser will attempt to work around such broken formatting ..." Which strongly suggests that the 'strict' flag defaults to True. However, it later says: "The strict flag defaults to False since lax parsing usually provides the most convenient behavior." I suggest the paragraph be reworded to avoid giving the impression that strict is True by default. Perhaps something like: "The optional strict flag specifies whether strict or lax parsing should be performed. When things like MIME terminating boundaries are missing, or when messages contain other formatting problems, the Parser will raise a MessageParseError if the strict flag is True. Otherwise, it uses lax parsing, and the Parser will attempt to work around such broken formatting to produce a usable message structure (this doesn't mean MessageParseErrors are never raised; some ill-formatted messages just can't be parsed). The strict flag defaults to False since lax parsing usually provides the most convenient behavior." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032960&group_id=5470 From noreply at sourceforge.net Wed Sep 22 22:51:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 22:51:43 2004 Subject: [ python-Bugs-1032960 ] Confusing description of strict option for email.Parser Message-ID: Bugs item #1032960, was opened at 2004-09-22 16:50 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032960&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Confusing description of strict option for email.Parser Initial Comment: The docs at http://www.python.org/dev/doc/devel/lib/node534.html say: "Normally, when things like MIME terminating boundaries are missing, or when messages contain other formatting problems, the Parser will raise a MessageParseError. However, when lax parsing is enabled, the Parser will attempt to work around such broken formatting ..." Which strongly suggests that the 'strict' flag defaults to True. However, it later says: "The strict flag defaults to False since lax parsing usually provides the most convenient behavior." I suggest the paragraph be reworded to avoid giving the impression that strict is True by default. Perhaps something like: "The optional strict flag specifies whether strict or lax parsing should be performed. When things like MIME terminating boundaries are missing, or when messages contain other formatting problems, the Parser will raise a MessageParseError if the strict flag is True. Otherwise, it uses lax parsing, and the Parser will attempt to work around such broken formatting to produce a usable message structure (this doesn't mean MessageParseErrors are never raised; some ill-formatted messages just can't be parsed). The strict flag defaults to False since lax parsing usually provides the most convenient behavior." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032960&group_id=5470 From noreply at sourceforge.net Thu Sep 23 01:48:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 01:48:42 2004 Subject: [ python-Bugs-1033038 ] Misleading error message in random.choice Message-ID: Bugs item #1033038, was opened at 2004-09-22 23:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading error message in random.choice Initial Comment: Giving random.choice(seq) an empty sequence leads to a misleading error message, as per this example: >>> import random; random.choice([]) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 231, in choice return seq[int(self.random() * len(seq))] IndexError: list index out of range A simple fix is to "assert len(seq) > 0" in the choice method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 From noreply at sourceforge.net Thu Sep 23 02:05:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 02:05:04 2004 Subject: [ python-Bugs-1033038 ] Misleading error message in random.choice Message-ID: Bugs item #1033038, was opened at 2004-09-22 18:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading error message in random.choice Initial Comment: Giving random.choice(seq) an empty sequence leads to a misleading error message, as per this example: >>> import random; random.choice([]) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 231, in choice return seq[int(self.random() * len(seq))] IndexError: list index out of range A simple fix is to "assert len(seq) > 0" in the choice method. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-22 19:05 Message: Logged In: YES user_id=80475 Perhaps I've been using it for too long, but I do not find the error message to misleading. Also, I like having this method as simple and lightweight as possible though it may be worthwhile to add a line to the docs, "If the sequence is emtpy, raises a TypeError." If someone accepts this request, it should implemented as a try/except rather than an assertion. That approach would also let you catch TypeErrors raised is the argument doesn't define __len__ and __getitem__, for example: random.choice(set('abc')) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 From noreply at sourceforge.net Thu Sep 23 05:58:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 05:58:28 2004 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 13:18 Message generated for change (Comment added) made by fgsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: Federico Schwindt (fgsch) Date: 2004-09-23 00:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 13:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Thu Sep 23 07:23:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 07:23:23 2004 Subject: [ python-Bugs-1029475 ] PEP 302 loader not carried through by reload function Message-ID: Bugs item #1029475, was opened at 2004-09-16 20:35 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stephen Haberman (filitov) Assigned to: Phillip J. Eby (pje) Summary: PEP 302 loader not carried through by reload function Initial Comment: This is based on bug 856103 "reload() fails with modules from zips", but only a fix for the PEP 302 loaders not being used in reload. There are other issues with reloading zip files, specifically when the size of the zip changes, new buffers are not created, but that is a separate issue and dealt with in bug 856103 instead of here. ---- This patch just modifies import.c's PyImport_ReloadModule to use a loader argument to find_module and load_module. A few things to note: 1) After my original 856103 patch was made, the path parameter to find_module now has to be non null. This path variable was only being set in the subname != NULL case off of the parent, so I copied the logic to get the path off of the existing module in the subname == NULL case. This seems to work. 2) I was fairly sure with my original 856103 patch, "reload(mod)" and then "mod.newFunction()" would work. But now the test case has to do "mod = reload(mod)" for the "newFunction()" call to work. I do not know whether this is related to something in this patch or not. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2004-09-23 05:23 Message: Logged In: YES user_id=56214 Fixed for 2.4 and the 2.3 maintenance branch, using simpler test code, and adding a missing Py_XDECREF to the C change. PEP 302 has also been updated to point out that loaders must use the existing module in sys.modules, if present, and the TestImporter in test_importhooks has been changed to do this. zipimport, however, does not do this, and that is a problem that still needs fixing (see bug #856103 for some other zipimport+reload issues). ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 22:38 Message: Logged In: YES user_id=642545 You're right, the path = m.__path__ stuff was all wrong. I was not initializing path to NULL in the first place. I've attached the updated patch. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2004-09-16 21:00 Message: Logged In: YES user_id=56214 Hi Stephen. I don't understand why 'path' has to be non-null. Not only that, but if it *is* null and the module has no __path__, your patch is still going to pass in a null path. So I'm confused. How did you discover the problem? Similarly, I'm confused as to why 'mod=reload(mod)' would be necessary now, but wasn't before. There have been no changes that I see in test_importhooks that would cause that. What was your testing methodology for this? ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 20:45 Message: Logged In: YES user_id=642545 Okay, this one is actually the patch, not the test case itself. Sheesh. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 20:41 Message: Logged In: YES user_id=642545 Attached the patch with a better test case. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 20:37 Message: Logged In: YES user_id=642545 Trying to upload the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029475&group_id=5470 From noreply at sourceforge.net Thu Sep 23 08:21:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 08:21:52 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 08:48 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options <module 'spambayes.Options' from 'c:\spambayes\windows\py2exe\dist\lib\spambayes .zip\spambayes\Options.pyc'> >>> reload(Options) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2004-09-23 06:21 Message: Logged In: YES user_id=56214 I've fixed bug #1029475, so reload() will now actually invoke the PEP 302 loader mechanism. However, there's another bug in zipimport: the loader implementation in zipimport.c always creates a new module, even when reloading. It needs to check sys.modules first, and reuse the existing module if present. I'm attempting to fix that issue now, and once I'm done, someone more familiar with zipimport's cache mechanism can do the rest. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 21:00 Message: Logged In: YES user_id=642545 Turns out there are two issues here: PEP 302 using the loader, and then the zip import caching the contents of zip files. At the suggestion of Phillip Eby, the PEP 302 stuff not using a loader has been put in a new bug that he is going to take care of: https://sourceforge.net/tracker/index.php?func=detail&aid=1029475&group_id=5470&atid=105470 So, now there is just the separate issue of the zip import not checking the file modification time. The attached patch makes sure when reload(aZipModule) is called that the file modification time is checked and that the contents are reloaded. More details are in my last comment. There is a test case that passes as well. The patch is at a more permanent location this time: http://www.chase3000.com/stephenh/patch-zipimport.txt ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 23:26 Message: Logged In: YES user_id=642545 Okay, so you talked me in to it. Besides the previous PyImport_ReloadModule patch, I modified zipimport.c to add another cache (zip_directory_cache of toc_entry's and zip_mtime_cache of modification times). On creation of a new ZipImporter or call to get_module_code, check_archive_mtime is called, which gets the new mtime and compares to the cached one. If they are different, it calls the old read_directory. read_directory was modified to, instead of creating a brand new path: [toc_entry] dictionary, clear and re-populate the same 'files' dictionary. This is so that if multiple ZipImporters are sharing an archive, and hence already sharing the same 'files' entry in zip_directory_cache, if one of them detects a new zip file and has the toc_entry's reloaded, the other ZipImporters will see the change to (as they all share the same dictionary). This was pretty much the same functionality before (sharing dictionaries), just that now read_directory clears/updates an exisitng one instead creating its own brand new one. Also, I had to add a sleep(1) call in testReload to ensure the modification time stamp would change. Again, either I don't have permissions to upload files, or I just can't figure it out, so the patch is at: http://sh5.beachead.com:8080/~stephen/patch.txt This is my first foray into Python coding, so double checking all of the reference counting inc/dec stuff would be a really good idea. I also took about 20 minutes to look at adding a reload test to test_importhooks.py, as suggested, but couldn't get it to work. I couldn't tell if it was because I was writing a flawed test (which is what I am suspecting) or if the PyImport_ReloadModule patch was not working. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 16:53 Message: Logged In: YES user_id=92689 Hm, I forgot about the caching of directory info. I don't think properly supporting reloading from zip files is worth the effort. It would be nice if it failed nicer, though. The reload patch is still cool, though, since it should fix reloading with PEP 302-style importers in general (yet zipimport may still choose not to support it). A reload test in test_importhooks.py would be a great addition. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 16:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 15:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 12:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 07:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 03:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 00:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Thu Sep 23 10:08:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 10:09:01 2004 Subject: [ python-Bugs-513866 ] Float/long comparison anomaly Message-ID: Bugs item #513866, was opened at 2002-02-06 13:33 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=513866&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) >Assigned to: Tim Peters (tim_one) Summary: Float/long comparison anomaly Initial Comment: Comparing a float and a long appears to convert the long to float and then compare the two floats. This strategy is a problem because the conversion might lose precision. As a result, == is not an equivalence relation and < is not an order relation. For example, it is possible to create three numbers a, b, and c such that a==b, b==c, and a!=c. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-23 04:08 Message: Logged In: YES user_id=31435 I'm on vacation, so I fixed this . The changes are so messy I doubt it will get backported to the 2.3 line, though (I'm not going to try -- someone else would need to volunteer for that). Lib/test/test_long.py 1.25 Misc/NEWS 1.1142 Objects/floatobject.c 2.133 ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2002-02-17 11:22 Message: Logged In: YES user_id=72053 It looks like the complication is not in finding an algorithm but rather in fitting it into the implementation. I'm not at all sure this is right, but glancing at the code, the comparison seems to happen in the function try_3way_compare in Objects/object.c, which calls PyNumber_CoerceEx if the types aren't equal. PyNumber_CoerceEx ends up calling float_coerce on x,n which "promotes" n to float, similar to what happens when you do mixed arithmetic (like x+n). My guess is that a suitable patch would go into try_3way_compare to specially notice when you're comparing a float and a long, and avoid the coercion. I'm unfamiliar enough with the implementation that I'd probably take a while to get it right, and still possibly end up forgetting to update a refcount or something, leading to leaked memory or mysterious crashes later. Anyway, no, this isn't real important to me, at least at the moment. It just wasn't clear whether there was any difficulty figuring out a useable algorithm. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-02-17 10:46 Message: Logged In: YES user_id=418174 I think there's a slightly more straightforward algorithm than the one that Paul Rubin (phr) suggested. Again, assume that x is a float and n is a long. We note first that the comparison is trivial unless x and n are both nonzero and have the same sign. We will therefore assume in the rest of this discussion that x and n are strictly positive; the case where they are negative is analogous. Every floating-point implementation has many numbers with the property that the least significant bit in those numbers' representations has a value of 1. In general, if the floating-point representation has k bits, then any integer in the range [2**(k-1),2**k) qualifies. Let K be any of these numbers; it doesn't matter which one. Precompute K and store it in both float and long form. This computation is exact because K is an integer that has an exact representation in floating-point form. It is now possible to compare x with K and n with K exactly, without conversion, because we already have K exactly in both forms. If x < K and n >= K, then x < n and we're done. If x > K and n <= K, then x > n and we're done. Otherwise, x and n are on the same side of K (possibly being equal to K). If x >= K and n >= K, then the LSB of x is at least 1, so we can convert x to long without losing information. Therefore, cmp(x, n) is cmp(long(x), n). If x <= K and n <= K, then then n is small enough that it has an exact representation as a float. Therefore cmp(x, n) is cmp(x, float(n)). So I don't think there's any profound algorithmic problem here. Unfortunately, I don't know enough about the details of how comparison is implemented to be willing to try my hand at a patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-17 10:31 Message: Logged In: YES user_id=31435 Paul, this isn't an intellectual challenge -- I expect any numerical programmer of ordinary skill could write code to compare a float to a long delivering the mathematically sensible result. There are several ways to do it. Adding "me too" votes doesn't change the priority. How about taking a whack at writing a patch if this is important to you? It's so low on the list of PythonLabs priorities I doubt I'll ever get to it (which is why I unassigned myself: an unassigned bug report is looking for someone to fix it, not a cheerleader <wink>). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2002-02-17 09:58 Message: Logged In: YES user_id=72053 Oops, I got confused about the order of the two args in the example below. I meant cmp(x,n) in the description and cmp(xl, n) in the code, rather than having n first. Anyway you get the idea. Now I should go back to bed ;-). ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2002-02-17 09:43 Message: Logged In: YES user_id=72053 I hope there's a simple solution to this--it's obvious what the right result should be mathematically if you compare 1L<<10000 with 0.0. It should not raise an error. If the documented behavior leads to raising an error, then there's a bug in the document. I agree that it's not the highest priority bug in the world, but it doesn't seem that complicated. If n is a long and x is a float, both >= 0, what happens if you do this, to implement cmp(n,x): xl = long(x) # if x has a fraction part and int part is == n, then x>n if float(xl)!=x and xl==n: return 1 return cmp(n, xl) If both are < 0, change 1 to -1 above. If x and n are of opposite sign, the positive one is greater. Unless I missed something (which is possible--I'm not too alert right now) the above should be ok in all cases. Basically you use long as the common type to convert to; you do lose information when converting a non-integer, but for the comparison with an integer, you don't need the lost information other than knowing whether it was nonzero, which you find out by converting the long back to a float. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-02-09 10:42 Message: Logged In: YES user_id=418174 I completely agree it's not a high-priority item, especially because it may be complicated to fix. I think that the fundamental problem is that there is no common type to which both float and long can be converted without losing information, which complicates both the definition and implementation of comparison. Accordingly, it might make sense to think about this issue in conjunction with future consideration of rational numbers. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-09 02:33 Message: Logged In: YES user_id=31435 I reopened this, but unassigned it since I can't justify working on it (the benefit/cost ratio of fixing it is down in the noise compared to other things that should be done). I no longer think we'd need a PEP to change the behavior, and agree it would be nice to change it. Changing it may surprise people expecting Python to work like C (C99 says that when integral -> floating conversion is in range but can't be done exactly, either of the closest representable floating numbers may be returned; Python inherits the platform C's behavior here for Python int -> Python float conversion (C long -> C double); when the conversion is out of range, C doesn't define what happens, and Python inherits that too before 2.2 (Infinities and NaNs are what I've seen most often, varying by platform); in 2.2 it raises OverflowError). I'm not sure it's possible for a<b and b<c and a==c, unless the platform C is inconsistent (meaning that (double)i for a fixed i returns the next-lowest double on some calls but the next-higher on others). This brute-force searcher didn't turn up any examples on my box: f = 2L**53 - 5 # straddle the representable-as-double limit nums = [f+i for i in range(50)] nums.extend(map(float, nums)) for a in nums: . for b in nums: . if not a < b: . continue . for c in nums: . if not b < c: . continue . if a >= c: . print `a`, `b`, `c` ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-02-07 10:33 Message: Logged In: YES user_id=418174 Here is yet another surprise: x=[1L<10000] y=[0.0] z=x+y Now I can execute x.sort() and y.sort() successfully, but z.sort blows up. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-02-07 08:28 Message: Logged In: YES user_id=418174 The difficulty is that as defined, < is not an order relation, because there exist values a, b, c such that a<b, b==c, and a==c. I believe that there also exist values such that a<b, b<c, and a==c. Under such circumstances, it is hard to understand how sort can work properly, whicn is my real concern. Do you really want to warn people that they shouldn't sort lists containing floats and longs? Moreover, it is not terribly difficult to define the comparisons so that == is an equivalence relation and < is an order relation. The idea is that for any floating-point system, there is a threshold T such that if x is a float value >=T, converting x to long will not lose information, and if x is a long value <=T, converting x to float will not lose information. Therefore, instead of always converting to long, it suffices to convert in a direction chosen by comparing the operands to T (without conversion) first. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-06 23:59 Message: Logged In: YES user_id=31435 Oops! I meant """ could lead to a different result than the explicit coercion in somefloat == float(somelong) """ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-06 23:52 Message: Logged In: YES user_id=31435 Since the coercion to float is documented and intended, it's not "a bug" (it's functioning as designed), although you may wish to argue for a different design, in which case making an incompatible change would first require a PEP and community debate. Information loss in operations involving floats comes with the territory, and I don't see a reason to single this particular case out as especially surprising. OTOH, I expect it would be especially surprising to a majority of users if the implicit coercion in somefloat == somelong could lead to a different result than the explicit coercion in long(somefloat) == somelong Note that the "long" type isn't unique here: the same is true of mixing Python ints with Python floats on boxes where C longs have more bits of precision than C doubles (e.g., Linux for IA64, and Crays). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=513866&group_id=5470 From noreply at sourceforge.net Thu Sep 23 15:41:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 15:41:42 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 08:48 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options <module 'spambayes.Options' from 'c:\spambayes\windows\py2exe\dist\lib\spambayes .zip\spambayes\Options.pyc'> >>> reload(Options) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2004-09-23 13:41 Message: Logged In: YES user_id=56214 D'oh! PyImport_AddModule() only creates a new module if it doesn't already exist in sys.modules, so there's nothing to fix on that point. Now what's needed is someone familiar with zipimport.c internals to review Stephen's patch at: http://www.chase3000.com/stephenh/patch-zipimport.txt and clean out its stderr prints. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2004-09-23 06:21 Message: Logged In: YES user_id=56214 I've fixed bug #1029475, so reload() will now actually invoke the PEP 302 loader mechanism. However, there's another bug in zipimport: the loader implementation in zipimport.c always creates a new module, even when reloading. It needs to check sys.modules first, and reuse the existing module if present. I'm attempting to fix that issue now, and once I'm done, someone more familiar with zipimport's cache mechanism can do the rest. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-09-16 21:00 Message: Logged In: YES user_id=642545 Turns out there are two issues here: PEP 302 using the loader, and then the zip import caching the contents of zip files. At the suggestion of Phillip Eby, the PEP 302 stuff not using a loader has been put in a new bug that he is going to take care of: https://sourceforge.net/tracker/index.php?func=detail&aid=1029475&group_id=5470&atid=105470 So, now there is just the separate issue of the zip import not checking the file modification time. The attached patch makes sure when reload(aZipModule) is called that the file modification time is checked and that the contents are reloaded. More details are in my last comment. There is a test case that passes as well. The patch is at a more permanent location this time: http://www.chase3000.com/stephenh/patch-zipimport.txt ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 23:26 Message: Logged In: YES user_id=642545 Okay, so you talked me in to it. Besides the previous PyImport_ReloadModule patch, I modified zipimport.c to add another cache (zip_directory_cache of toc_entry's and zip_mtime_cache of modification times). On creation of a new ZipImporter or call to get_module_code, check_archive_mtime is called, which gets the new mtime and compares to the cached one. If they are different, it calls the old read_directory. read_directory was modified to, instead of creating a brand new path: [toc_entry] dictionary, clear and re-populate the same 'files' dictionary. This is so that if multiple ZipImporters are sharing an archive, and hence already sharing the same 'files' entry in zip_directory_cache, if one of them detects a new zip file and has the toc_entry's reloaded, the other ZipImporters will see the change to (as they all share the same dictionary). This was pretty much the same functionality before (sharing dictionaries), just that now read_directory clears/updates an exisitng one instead creating its own brand new one. Also, I had to add a sleep(1) call in testReload to ensure the modification time stamp would change. Again, either I don't have permissions to upload files, or I just can't figure it out, so the patch is at: http://sh5.beachead.com:8080/~stephen/patch.txt This is my first foray into Python coding, so double checking all of the reference counting inc/dec stuff would be a really good idea. I also took about 20 minutes to look at adding a reload test to test_importhooks.py, as suggested, but couldn't get it to work. I couldn't tell if it was because I was writing a flawed test (which is what I am suspecting) or if the PyImport_ReloadModule patch was not working. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 16:53 Message: Logged In: YES user_id=92689 Hm, I forgot about the caching of directory info. I don't think properly supporting reloading from zip files is worth the effort. It would be nice if it failed nicer, though. The reload patch is still cool, though, since it should fix reloading with PEP 302-style importers in general (yet zipimport may still choose not to support it). A reload test in test_importhooks.py would be a great addition. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 16:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 15:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 12:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 07:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 03:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 00:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Thu Sep 23 15:58:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 15:58:44 2004 Subject: [ python-Bugs-1033390 ] build doesn't pick up bsddb w/Mandrake 9.2 Message-ID: Bugs item #1033390, was opened at 2004-09-23 15:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: build doesn't pick up bsddb w/Mandrake 9.2 Initial Comment: Mandrake 9.2 installs bsddb 4.1 under /usr/lib, and apparently Python 2.4a3's setup.py doesn't pick it up -- adding /usr/lib to the list of directories where bsddb 4 is being searched for, and rerunning make, seems to fix the problem. (Problem does not appear on Mandrake 9.1, where I had installed sleepycat's stuff under /usr/local/BerkeleyDB.4.1 "by hand"; nor on MacOSX, where I had a fink-installed one in /sw/lib; no similar problem with any other module on any of these platforms, except bsddb). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 From noreply at sourceforge.net Thu Sep 23 16:19:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 16:19:16 2004 Subject: [ python-Bugs-1017864 ] Case sensitivity bug in ConfigParser Message-ID: Bugs item #1017864, was opened at 2004-08-27 16:26 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: Case sensitivity bug in ConfigParser Initial Comment: (Assume an instantiated ConfigParser, c, with a loaded file) >>> c.get("DEFAULT", "foo", False, {"foo": "Bar"}) 'Bar' >>> c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) Traceback (most recent call last): File "", line 1, in ? c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) File "C:\Python23\lib\ConfigParser.py", line 513, in get raise NoOptionError(option, section) NoOptionError: No option 'foo' in section: 'DEFAULT' The offending code appears to be as follows (in ConfigParser.py): def get(self, section, option): opt = self.optionxform(option) if section not in self._sections: if section != DEFAULTSECT: raise NoSectionError(section) if opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) elif opt in self._sections[section]: return self._sections[section][opt] elif opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) It uses optionxform on the supplied option, but not on the one in the defaults dictionary. If you're going to impose a transform then you have to do it consistently, imho... >>> c.get("DEFAULT", "Foo", False, {"foo": "Bar"}) 'Bar' The supplied "Foo" gets transformed to "foo" and matches the one in the defaults dictionary. Seems a bit counterintuitive to expect that you supply any defaults as pre-transformed according to your specified optionxform. I'm not sure if this is also a problem when reading a file, but there seems to be a related post about this (with no replies!) dating back to 2000: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=8suc1f%24mf9%241%40nnrp1.deja.com I don't have time to look into it now but I'd guess this problem was resolved in the more obvious location (when reading a file) but patching of the defaults dictionary case was omitted. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-09-23 10:19 Message: Logged In: YES user_id=7733 Patches added for ConfigParser.py and test_cfgparser.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 From noreply at sourceforge.net Thu Sep 23 16:20:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 16:20:45 2004 Subject: [ python-Bugs-1017864 ] Case sensitivity bug in ConfigParser Message-ID: Bugs item #1017864, was opened at 2004-08-27 16:26 Message generated for change (Settings changed) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Dani (asqui) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Case sensitivity bug in ConfigParser Initial Comment: (Assume an instantiated ConfigParser, c, with a loaded file) >>> c.get("DEFAULT", "foo", False, {"foo": "Bar"}) 'Bar' >>> c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) Traceback (most recent call last): File "", line 1, in ? c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) File "C:\Python23\lib\ConfigParser.py", line 513, in get raise NoOptionError(option, section) NoOptionError: No option 'foo' in section: 'DEFAULT' The offending code appears to be as follows (in ConfigParser.py): def get(self, section, option): opt = self.optionxform(option) if section not in self._sections: if section != DEFAULTSECT: raise NoSectionError(section) if opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) elif opt in self._sections[section]: return self._sections[section][opt] elif opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) It uses optionxform on the supplied option, but not on the one in the defaults dictionary. If you're going to impose a transform then you have to do it consistently, imho... >>> c.get("DEFAULT", "Foo", False, {"foo": "Bar"}) 'Bar' The supplied "Foo" gets transformed to "foo" and matches the one in the defaults dictionary. Seems a bit counterintuitive to expect that you supply any defaults as pre-transformed according to your specified optionxform. I'm not sure if this is also a problem when reading a file, but there seems to be a related post about this (with no replies!) dating back to 2000: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=8suc1f%24mf9%241%40nnrp1.deja.com I don't have time to look into it now but I'd guess this problem was resolved in the more obvious location (when reading a file) but patching of the defaults dictionary case was omitted. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-09-23 10:19 Message: Logged In: YES user_id=7733 Patches added for ConfigParser.py and test_cfgparser.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 From noreply at sourceforge.net Thu Sep 23 16:22:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 16:22:05 2004 Subject: [ python-Bugs-1017864 ] Case sensitivity bug in ConfigParser Message-ID: Bugs item #1017864, was opened at 2004-08-27 16:26 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Dani (asqui) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Case sensitivity bug in ConfigParser Initial Comment: (Assume an instantiated ConfigParser, c, with a loaded file) >>> c.get("DEFAULT", "foo", False, {"foo": "Bar"}) 'Bar' >>> c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) Traceback (most recent call last): File "", line 1, in ? c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) File "C:\Python23\lib\ConfigParser.py", line 513, in get raise NoOptionError(option, section) NoOptionError: No option 'foo' in section: 'DEFAULT' The offending code appears to be as follows (in ConfigParser.py): def get(self, section, option): opt = self.optionxform(option) if section not in self._sections: if section != DEFAULTSECT: raise NoSectionError(section) if opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) elif opt in self._sections[section]: return self._sections[section][opt] elif opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) It uses optionxform on the supplied option, but not on the one in the defaults dictionary. If you're going to impose a transform then you have to do it consistently, imho... >>> c.get("DEFAULT", "Foo", False, {"foo": "Bar"}) 'Bar' The supplied "Foo" gets transformed to "foo" and matches the one in the defaults dictionary. Seems a bit counterintuitive to expect that you supply any defaults as pre-transformed according to your specified optionxform. I'm not sure if this is also a problem when reading a file, but there seems to be a related post about this (with no replies!) dating back to 2000: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=8suc1f%24mf9%241%40nnrp1.deja.com I don't have time to look into it now but I'd guess this problem was resolved in the more obvious location (when reading a file) but patching of the defaults dictionary case was omitted. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-09-23 10:22 Message: Logged In: YES user_id=7733 Should be applied prior to 2.4-beta-1. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-09-23 10:19 Message: Logged In: YES user_id=7733 Patches added for ConfigParser.py and test_cfgparser.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 From noreply at sourceforge.net Thu Sep 23 16:28:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 16:28:42 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-09-23 10:28 Message: Logged In: YES user_id=7733 I have come up with a solution that should satisfy everyone. Python 2.4's ConfigParser.py has added a new SafeConfigParser class, so the new string-only restriction should be added to the new class. Existing behavior is now documented and remains valid, so there should be no code breakage. But new users will get the "safe" string-only behavior from SafeConfigParser. Patches added for ConfigParser.py, test_cfgparser.py, and libcfgparser.tex. This should be applied prior to Python 2.4-beta-1. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-30 13:26 Message: Logged In: YES user_id=7733 [anthonybaxter] > RCP isn't in __all__, Perhaps it should be, because: > and isn't documented, Actually, it is documented: http://www.python.org/dev/doc/devel/lib/RawConfigParser-objects.html > we can also put a type check in the > output code to make sure it gets picked up there... It gets more and more complicated, doesn't it? I still think that the code itself wasn't broken so there was no need to fix it. The simplest solution would be to revert the rev 1.65 code changes, and just add some documentation. Something along the lines of: "Output only works with string values. If used for non-string values, you're on your own." We shouldn't be *removing* functionality without a darned good reason. I don't see such a reason here. And since this change broke preexisting code that relied on that functionality, it seems obvious that it should be reverted. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-30 12:18 Message: Logged In: YES user_id=29957 I can live with David's last solution (moving the type check to CP.set). RCP isn't in __all__, and isn't documented, so I don't think it matters so much if it has internally inconsistent results - we can also put a type check in the output code to make sure it gets picked up there... ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 23:34 Message: Logged In: YES user_id=7733 [rhettinger] > Perhaps, the set() method should coerce to a string rather > than test for it. Perhaps. But regardless of whether it's a test or coercion, if it's in RawConfigParser.set, it prevents non-string use. Perhaps ConfigParser.set should extend RawConfigParser.set with the string test or coercion, leaving RawConfigParser.set as it was before rev 1.65. That may be the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 12:10 Message: Logged In: YES user_id=80475 Perhaps, the set() method should coerce to a string rather than test for it. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Fri Sep 24 00:55:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 00:55:55 2004 Subject: [ python-Bugs-1033720 ] buffer() object broken. Message-ID: Bugs item #1033720, was opened at 2004-09-23 18:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: buffer() object broken. Initial Comment: This bug breaks Twisted. print str(buffer(buffer("asdf", 0), 0, 131072)) On Python < 2.4, this prints 'asdf' as it should. On Python 2.4, this prints '', as it most certainly *should not*. It may have something to do with: Python 2.4a2 (#61, Sep 9 2004, 22:24:36) >>> buffer("asdf", 0) (size -1, WTF??) vs. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) >>> buffer("asdf", 0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 From noreply at sourceforge.net Fri Sep 24 02:30:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 02:30:30 2004 Subject: [ python-Bugs-874354 ] ConfigParser's get method gives utf-8 for a utf-16 config... Message-ID: Bugs item #874354, was opened at 2004-01-10 05:36 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874354&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Toyotomi Hideyoshi (kaishaku) >Assigned to: David Goodger (goodger) Summary: ConfigParser's get method gives utf-8 for a utf-16 config... Initial Comment: If I load a utf-16 document and do cfgparser.get, I get a utf-8 string. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-09-23 20:30 Message: Logged In: YES user_id=7733 It has been 8 months with no response/clarification/example from kaishaku, so I'm closing the bug report. Kaishaku, if you provide an example, we may re-open the bug report. If English is a problem, I read and write Japanese; you can send email to me directly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-17 18:59 Message: Logged In: YES user_id=21627 Can you provide a complete example? To my knowledge, ConfigParser does not support utf-16 at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874354&group_id=5470 From noreply at sourceforge.net Fri Sep 24 17:24:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 17:24:40 2004 Subject: [ python-Bugs-1033720 ] buffer() object broken. Message-ID: Bugs item #1033720, was opened at 2004-09-23 22:55 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) >Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: This bug breaks Twisted. print str(buffer(buffer("asdf", 0), 0, 131072)) On Python < 2.4, this prints 'asdf' as it should. On Python 2.4, this prints '', as it most certainly *should not*. It may have something to do with: Python 2.4a2 (#61, Sep 9 2004, 22:24:36) >>> buffer("asdf", 0) (size -1, WTF??) vs. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) >>> buffer("asdf", 0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 From noreply at sourceforge.net Fri Sep 24 17:43:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 17:43:39 2004 Subject: [ python-Bugs-1033720 ] buffer() object broken. Message-ID: Bugs item #1033720, was opened at 2004-09-23 22:55 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Neil Schemenauer (nascheme) Summary: buffer() object broken. Initial Comment: This bug breaks Twisted. print str(buffer(buffer("asdf", 0), 0, 131072)) On Python < 2.4, this prints 'asdf' as it should. On Python 2.4, this prints '', as it most certainly *should not*. It may have something to do with: Python 2.4a2 (#61, Sep 9 2004, 22:24:36) >>> buffer("asdf", 0) (size -1, WTF??) vs. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) >>> buffer("asdf", 0) ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2004-09-24 15:43 Message: Logged In: YES user_id=35752 Fixed in bufferobject.c 2.25. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470 From noreply at sourceforge.net Fri Sep 24 18:33:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 18:33:44 2004 Subject: [ python-Bugs-1034178 ] Can't inherit slots from new-style classes implemented in C Message-ID: Bugs item #1034178, was opened at 2004-09-24 17:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034178&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: Can't inherit slots from new-style classes implemented in C Initial Comment: I have a new-style class implemented in C which defines slots (eg. puts a C function pointer in mp_length). It does not create a __len__ entry in the class dictionary. If I sub-class it in Python then the slot is not inherited. The function pointer is copied correctly by inherit_slots() (in typeobject.c). The problem occurs in update_one_slot(). The call to _PyType_Lookup() fails because the slot does not have an entry in the class dictionary. This causes the valid function pointer to be overwritten with the value of "specific" which is 0. The following patch fixes the problem - but I'm not sure it is the correct fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034178&group_id=5470 From noreply at sourceforge.net Fri Sep 24 20:10:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 20:10:34 2004 Subject: [ python-Bugs-1034242 ] More buffer object brokenness Message-ID: Bugs item #1034242, was opened at 2004-09-24 14:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034242&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: More buffer object brokenness Initial Comment: Thanks for fixing the last bug so quickly. Here's some more tests to add that currently fail with 2.4 and not with 2.3. Negative offsets should always be forbidden, and you should not be able to extend the length of a nested buffer by giving a longer length on the outer one. try: buffer(buffer('asdf', 1), -1) except ValueError: pass else: raise TestFailed, "buffer(buffer('asdf', 1), -1) should raise ValueError" if str(buffer(buffer('asdf', 0, 2), 0)) != 'as': raise TestFailed, 'composing length-specified buffer failed' if str(buffer(buffer('asdf', 0, 2), 0, 5000)) != 'as': raise TestFailed, 'composing length-specified buffer with length on outer failed' if str(buffer(buffer('asdf', 0, 2), 0, -1)) != 'as': raise TestFailed, 'composing length-specified buffer with -1 length on outer failed' if str(buffer(buffer('asdf', 0, 2), 1, 2)) != 's': raise TestFailed, 'composing length-specified buffer with length and offset on outer failed' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034242&group_id=5470 From noreply at sourceforge.net Fri Sep 24 21:05:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 21:05:19 2004 Subject: [ python-Bugs-1034277 ] Why does Python link to Foundation? Message-ID: Bugs item #1034277, was opened at 2004-09-24 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Why does Python link to Foundation? Initial Comment: I can't see any reason for Python to link to Foundation, so I don't think it should. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 From noreply at sourceforge.net Fri Sep 24 21:19:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 21:19:42 2004 Subject: [ python-Bugs-1034242 ] More buffer object brokenness Message-ID: Bugs item #1034242, was opened at 2004-09-24 18:10 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034242&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James Y Knight (foom) >Assigned to: Neil Schemenauer (nascheme) Summary: More buffer object brokenness Initial Comment: Thanks for fixing the last bug so quickly. Here's some more tests to add that currently fail with 2.4 and not with 2.3. Negative offsets should always be forbidden, and you should not be able to extend the length of a nested buffer by giving a longer length on the outer one. try: buffer(buffer('asdf', 1), -1) except ValueError: pass else: raise TestFailed, "buffer(buffer('asdf', 1), -1) should raise ValueError" if str(buffer(buffer('asdf', 0, 2), 0)) != 'as': raise TestFailed, 'composing length-specified buffer failed' if str(buffer(buffer('asdf', 0, 2), 0, 5000)) != 'as': raise TestFailed, 'composing length-specified buffer with length on outer failed' if str(buffer(buffer('asdf', 0, 2), 0, -1)) != 'as': raise TestFailed, 'composing length-specified buffer with -1 length on outer failed' if str(buffer(buffer('asdf', 0, 2), 1, 2)) != 's': raise TestFailed, 'composing length-specified buffer with length and offset on outer failed' ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2004-09-24 19:19 Message: Logged In: YES user_id=35752 Fixed in bufferobject.c 2.26. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034242&group_id=5470 From noreply at sourceforge.net Fri Sep 24 23:58:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 23:58:55 2004 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 09:05 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 23:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Sat Sep 25 00:00:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 00:00:22 2004 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 09:05 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-25 00:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 23:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Sat Sep 25 01:26:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 01:26:25 2004 Subject: [ python-Bugs-921077 ] embedding in multi-threaded & multi sub-interpreter environ Message-ID: Bugs item #921077, was opened at 2004-03-22 07:39 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Atul (atulkshirsagar) Assigned to: Brett Cannon (bcannon) Summary: embedding in multi-threaded & multi sub-interpreter environ Initial Comment: I am embedding python in my C++ application. I am using Python *2.3.2* with a C++ extention DLL in multi- threaded environment. I am using SWIG-1.3.19 to generate C++ to Python interface. Now to explain it in details, 1. Python initialization [Py_Initialize()] and finalization [Py_Finalize()] is done in the *main* thread. 2. For each new thread I create a separate sub- interpreter [Py_NewInterpreter()]. 3. Using PyRun_String("import myModule"...) before execution of python script, extention module is imported. 4. Each thread executes *multiple* python script using PyEval_EvalCode() using the class objects in my extention DLL. 5. Each sub-interpreter is destroyed [Py_EndInterpreter ()] at the end of that particular thread. I am observing that; As explained above when multiple threads are running. And as one of these threads finishes, in other running threads I start getting "TypeError: 'NoneType' object is not callable" error on the methods called on class objects in extention module. The same code *works fine* with Python 2.2.2. I have found these links more or less talking about the same problem migrating from 2.2 to 2.3. http://mail.python.org/pipermail/python-dev/2003- September/038237.html http://mail.python.org/pipermail/python-list/2004- February/206851.html http://mail.python.org/pipermail/python-list/2004- January/204040.html I *guess* what is happening is global variables are zapped to "NoneType" when one thread finishes and other thread trying to access them through the Python script (step 4.) this error is generated. But it *works* sometimes when(*guess*) the running thread is at step 3. and by importing the module the global variables are re-initialized for "Type" information. I tried using reload(myModule) to solve the problem but that is generating big memory leak every time it is called. Is this a know issue with 2.3 (interpreter?) ? Or is there a change for 2.3 in the way embedding should be done in a multi-threaded and multi-sub-interpreter environment ? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-24 16:26 Message: Logged In: YES user_id=357491 OK, since the OP has not responded to this and I suspect this is the same bug that got squashed a while back with exceptions not getting reported at teardown time by threads, I am closing this as outdated. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:46 Message: Logged In: YES user_id=357491 Have you tried this with the fixes added in 2.3.4 or 2.4? Should print out proper tracebacks now. ---------------------------------------------------------------------- Comment By: Atul (atulkshirsagar) Date: 2004-04-05 13:16 Message: Logged In: YES user_id=1003784 Hello, Did you get a chance to take a look at this yet ? Thanks, Atul ---------------------------------------------------------------------- Comment By: Atul (atulkshirsagar) Date: 2004-04-01 12:12 Message: Logged In: YES user_id=1003784 Hello Martin, I am attaching the sample program which demonstrates the issue; 1. I compiled it on Windows 2000 with VC++ compiler. 2. There is a "Extension Module" [flpythonmodulesu(d).dll] which is used by "Main" program ========================================= Extension Module (extModule.dsp project) generates : (*u.* - release, *ud.* - debug) 1. dll _flpythonmodulesud.dll 2. python script flpythonmodulesud.py ------------------------------------------------------ 1. Module has class FlPythonString and class Record defined 2. Using interface file include\flpythonmodulesud.i, SWIG- 1.3.19 generates include\flpythonmodulesud_wrap.cxx =========================================== ========================================= Main sample program (multiSub.dsp project) generates : 1. executable multiSub.exe ------------------------------------------------------ 1. Links in the extension DLL 2. Initializes and De-initializes python in main thread 3. Main thread creates 2 separate threads: (a) Each thread creating a new sub-interpreter (b) importing extension module (c) Calling following EXPRESSION using PyEval_EvalCode(), Thread 1: myVar = FlPythonStringPtr(STRObject) myRecord = myVar.NewRecord() Thread=str(myVar.Get()) record=str(myRecord.GetValue()) print 'Inside EXPRESSION ' + Thread + ':' + record;myVar.DeleteRecord(myRecord) Thread 2: myVar = FlPythonStringPtr(STRObject) for recordNum in range(1, 11): myRecord = myVar.NewRecord() Thread=str(myVar.Get()) record=str(myRecord.GetValue()) print 'Inside EXPRESSION ' + Thread + ':' + record;myVar.DeleteRecord(myRecord) (d) Destroying sub-interpreter. Comments in the code explain details about each step. =========================================== ========================================== Console Output messages explanations (Attaching a sample console output for the issue [consoleop.txt]) ----------------------------------------------------- -Thread *ID*:IMPORT Module Called:*ITERATION* -Inside EXPRESSION *Thread*:*Record::GetValue() [hardcoded to 1000]* -Thread *ID*:EXPRESSION Done:*ITERATION* -Thread *ID*:ENDINTERPRETER Called -Thread *ID*:EXPRESSION Failed!:*ITERATION* Check the error message demonstrating the issue: ----------------------------------------------- "Thread 2:EXPRESSION Failed!:3 Traceback (most recent call last): File "EXPRESSION", line 4, in ? File "E:\VssLocal\Isis\python23_issue\multiSub\Debug\flpython modulesud.py", line 69, in Get def Get(*args): return apply (_flpythonmodulesud.FlPythonString_Get,args) File "E:\VssLocal\Isis\python23_issue\multiSub\Debug\flpython modulesud.py", line 51, in __init__ _swig_setattr(self, Record, 'this', this) TypeError: 'NoneType' object is not callable" ========================================== Martin, Thanks for taking a look at the issue which has proved to be a major hurdle for our release and made us switch back to Python 2.2.2. Python 2.2.2 in itself has some issues for us; so if this can get fixed we would desperately be seeking a patch on Python 2.3. Let me know if you need any more inputs from my side. Thanks again, Atul ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 14:28 Message: Logged In: YES user_id=21627 Can you provide an example that demonstrates the supposed bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470 From noreply at sourceforge.net Sat Sep 25 03:58:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 03:58:33 2004 Subject: [ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning Message-ID: Bugs item #997100, was opened at 2004-07-24 11:20 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Charles (melicertes) Assigned to: Greg Ward (gward) Summary: optparse.py:668 triggers FutureWarning Initial Comment: In Python 2.3.3, importing optparse triggers a FutureWarning on line 668: > /usr/local/lib/python2.3/optparse.py:668: FutureWarning: > %u/%o/%x/%X of negative int will return a signed string in > Python 2.4 and up > return ("<%s at 0x%x: %r>" ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2004-09-24 21:58 Message: Logged In: YES user_id=14422 You didn't specify which OS this happens on; I bet it was Fedora Core or RHEL 3.0, right? (I found a related thread on python-dev, and ISTR it was related to the SE-Linux changes fiddling how the userspace heap fits into VM.) I'm checking in a change to optik/lib/option.py that should suppress the warning. I'm not sure this is the right thing to do, though, since 1) I can't reproduce it, and 2) I don't think it will be an issue under Python 2.4, with the continuing unification of int and long. See http://mail.python.org/pipermail/python-dev/2003-November/039952.html and following messages. Perhaps the right thing to do is just fix this in optparse.py on the Python 2.3 branch and forget about Optik or Python 2.4. Hmmm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470 From noreply at sourceforge.net Sat Sep 25 03:58:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 03:59:06 2004 Subject: [ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning Message-ID: Bugs item #997100, was opened at 2004-07-24 11:20 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 3 Submitted By: Charles (melicertes) Assigned to: Greg Ward (gward) Summary: optparse.py:668 triggers FutureWarning Initial Comment: In Python 2.3.3, importing optparse triggers a FutureWarning on line 668: > /usr/local/lib/python2.3/optparse.py:668: FutureWarning: > %u/%o/%x/%X of negative int will return a signed string in > Python 2.4 and up > return ("<%s at 0x%x: %r>" ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2004-09-24 21:58 Message: Logged In: YES user_id=14422 Marking this fixed, but not closing it, pending a checkin to optparse.py on Python 2.3 branch and confirmation that it actually helped. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2004-09-24 21:58 Message: Logged In: YES user_id=14422 You didn't specify which OS this happens on; I bet it was Fedora Core or RHEL 3.0, right? (I found a related thread on python-dev, and ISTR it was related to the SE-Linux changes fiddling how the userspace heap fits into VM.) I'm checking in a change to optik/lib/option.py that should suppress the warning. I'm not sure this is the right thing to do, though, since 1) I can't reproduce it, and 2) I don't think it will be an issue under Python 2.4, with the continuing unification of int and long. See http://mail.python.org/pipermail/python-dev/2003-November/039952.html and following messages. Perhaps the right thing to do is just fix this in optparse.py on the Python 2.3 branch and forget about Optik or Python 2.4. Hmmm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470 From noreply at sourceforge.net Sat Sep 25 10:52:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 10:52:25 2004 Subject: [ python-Bugs-1034496 ] Configure uses GNU ld flags with non-GNU compilers/linkers Message-ID: Bugs item #1034496, was opened at 2004-09-25 01:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034496&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Drew Schatt (dschatt) Assigned to: Nobody/Anonymous (nobody) Summary: Configure uses GNU ld flags with non-GNU compilers/linkers Initial Comment: I was just attempting to build Python 2.3.4 on Solaris 9, using Sun's Compilers and linkers (/opt/SUNWspro/bin/cc and /usr/ccs/ bin/ld). The configure script correctly determined that I was not using either GNU gcc or GNU ld. However, it continued to put GNU specific variables into the Makefile (specifically, -Wl,). This broke several things, until I manually removed them. The first place it broke was when it created the shared library, which, because of the different ways that Sun's linker and GNU ld handle options, ended up being named "name\=libpython2.3.so.1.0" because Sun's compiler detected two -o flags (the first being in the -Wl,-soname=libpython2.3.so.1.0 -o libpython2.3.so.1.0) - and Sun's linker takes the first -o flag it sees (it helpfully tells you that, though). So... the GNU specific flags need to ONLY be used if the GNU ld/ gcc are being used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034496&group_id=5470 From noreply at sourceforge.net Sat Sep 25 13:27:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 13:27:53 2004 Subject: [ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning Message-ID: Bugs item #997100, was opened at 2004-07-24 17:20 Message generated for change (Comment added) made by m-a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 3 Submitted By: Charles (melicertes) Assigned to: Greg Ward (gward) Summary: optparse.py:668 triggers FutureWarning Initial Comment: In Python 2.3.3, importing optparse triggers a FutureWarning on line 668: > /usr/local/lib/python2.3/optparse.py:668: FutureWarning: > %u/%o/%x/%X of negative int will return a signed string in > Python 2.4 and up > return ("<%s at 0x%x: %r>" ---------------------------------------------------------------------- Comment By: Matthias Andree (m-a) Date: 2004-09-25 13:27 Message: Logged In: YES user_id=2788 I for one have seen the warning with a Python 2.3.4 I compiled myself (based on SuSE's 2.3.3 source RPM) on SuSE Linux 9.1. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2004-09-25 03:58 Message: Logged In: YES user_id=14422 Marking this fixed, but not closing it, pending a checkin to optparse.py on Python 2.3 branch and confirmation that it actually helped. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2004-09-25 03:58 Message: Logged In: YES user_id=14422 You didn't specify which OS this happens on; I bet it was Fedora Core or RHEL 3.0, right? (I found a related thread on python-dev, and ISTR it was related to the SE-Linux changes fiddling how the userspace heap fits into VM.) I'm checking in a change to optik/lib/option.py that should suppress the warning. I'm not sure this is the right thing to do, though, since 1) I can't reproduce it, and 2) I don't think it will be an issue under Python 2.4, with the continuing unification of int and long. See http://mail.python.org/pipermail/python-dev/2003-November/039952.html and following messages. Perhaps the right thing to do is just fix this in optparse.py on the Python 2.3 branch and forget about Optik or Python 2.4. Hmmm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470 From noreply at sourceforge.net Sat Sep 25 19:46:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 19:46:37 2004 Subject: [ python-Bugs-1033038 ] Misleading error message in random.choice Message-ID: Bugs item #1033038, was opened at 2004-09-22 18:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) >Assigned to: Tim Peters (tim_one) Summary: Misleading error message in random.choice Initial Comment: Giving random.choice(seq) an empty sequence leads to a misleading error message, as per this example: >>> import random; random.choice([]) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 231, in choice return seq[int(self.random() * len(seq))] IndexError: list index out of range A simple fix is to "assert len(seq) > 0" in the choice method. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 12:46 Message: Logged In: YES user_id=80475 Tim, I'm -1 on this one. What do you think? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-22 19:05 Message: Logged In: YES user_id=80475 Perhaps I've been using it for too long, but I do not find the error message to misleading. Also, I like having this method as simple and lightweight as possible though it may be worthwhile to add a line to the docs, "If the sequence is emtpy, raises a TypeError." If someone accepts this request, it should implemented as a try/except rather than an assertion. That approach would also let you catch TypeErrors raised is the argument doesn't define __len__ and __getitem__, for example: random.choice(set('abc')) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 From noreply at sourceforge.net Sat Sep 25 19:47:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 19:47:34 2004 Subject: [ python-Bugs-1031897 ] Conflicting descriptions of application order of decorators Message-ID: Bugs item #1031897, was opened at 2004-09-21 08:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Hamish Lawson (hamishlawson) Assigned to: A.M. Kuchling (akuchling) Summary: Conflicting descriptions of application order of decorators Initial Comment: The explanation of decorators in "What's new in Python 2.4" has the application order opposite to that stated in the Reference Manual. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2004-09-21 10:16 Message: Logged In: YES user_id=233844 And the PEP 318 is in conflict with the "What's new in Python 2.4" but in accordance with the manual. So it is very probably a problem in the what'snew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031897&group_id=5470 From noreply at sourceforge.net Sat Sep 25 19:50:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 19:52:26 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 12:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 12:50 Message: Logged In: YES user_id=80475 Tim, can this be marked as fixed and closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 22:25 Message: Logged In: YES user_id=31435 Zope3's problem w/ asyncore appears to be fixed. Thanks! WRT > Therefore, I think the 'if is_r or is_w' logic is necessary. I expect you're right. I think I had vaguely in mind that "the usual" implementation of fdsets represents them as bit vectors, so that redundancy wouldn't hurt. But that's not the only part of the story, and I overlooked that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 09:08 Message: Logged In: YES user_id=11375 Original patch committed as rev. 1.61 of asyncore.py. I'm leaving the bug open until Tim (or someone) reports that the problem is fixed. poll2 (the one that uses select.poll()) should automatically remove objects for which POLLNVAL is set -- that's what the error means, after all. I'll worry about that after 2.3alpha3 is released. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 08:32 Message: Logged In: YES user_id=11375 'e = r+w' means 'e' can contain the same descriptor twice, if it's both readable and writable, and I think this matters. Duplicate fd's don't cause a problem with the select() system call itself, but the return value from select.select() would include the file descriptor twice. (I've attached a test program that demonstrates this for readable fds.) Therefore, I think the 'if is_r or is_w' logic is necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 11:49 Message: Logged In: YES user_id=31435 Logic similar to the logic in the patch worked for me when I tried it. Suggest it would be faster and clearer to just add e = r + w to the 2.3 asyncore poll(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 11:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 11:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 06:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Sat Sep 25 19:53:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 19:53:42 2004 Subject: [ python-Bugs-1010098 ] CPU usage shoots up with asyncore Message-ID: Bugs item #1010098, was opened at 2004-08-16 10:54 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Thomas (thomasabc) Assigned to: A.M. Kuchling (akuchling) Summary: CPU usage shoots up with asyncore Initial Comment: The CPU usage of a python application program using asyncore.py shoot up to 99% under Python 2.4a1. After a comparison, it was found out that the same program ran without such high CPU usage under Python 2.3.3 A simple couple of programs to narrow down the problem showed that a single loop() was accompanied by a large number of poll() with 2.4a1, whereas a single loop() had only 3 calls to poll() with 2.3.3. Please let me know if there is anything else I can do for you to analyse. A couple of python scripts are attached in a zip file for you as below: - Summary of the test scripts With these scripts, the test attempts to identify what function calls are called that might explain the high CPU usage observed. asyncore_test.py: Taken from the Python Library Reference 11.24.2 asynchat Example, the test program starts a server process to simulate client request process. http_test.py: This program simply establishes connection to the server and closes after 10 seconds. - Procedure 1. Start asyncore_test.py 2. Start http_test.py 3. Stop asyncore_test.py ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-21 18:01 Message: Logged In: YES user_id=31435 I can confirm the primary symptom on WinXP. For the 10 seconds http_test.py runs, CPU is nailed to the wall under current CVS Python, but is a trickle under 2.3.4. asyncore appears to be irrelevant. "The problem" is that the socket associated with __main__.http_request_handler always comes back in the w set from select.select() under current Python, but the select times out under 2.3.4. More detail: under current Python, dumping some prints in asyncore.poll() delivers a huge number of repetitions of this info: socket map is {1940: <__main__.http_request_handler connected 127.0.0.1:3455 at 0x9da800>, 1948: <__main__.AsyncHTTPServer listening :40004 at 0x9d7fa8>} r, w, e passed in is [1940, 1948] [1940, 1948] [1940, 1948] r, w, e returned is [], [1940], [] Under 2.3.4, there are only a few lines of output total -- select() doesn't believe the sockets passed to it are ready to read or ready to write. So the difference is in socket behavior, or in how the layers around asyncore here are using sockets. ---------------------------------------------------------------------- Comment By: Thomas (thomasabc) Date: 2004-08-20 05:05 Message: Logged In: YES user_id=1104845 Sorry, just to let you know that you press Ctrl+C to stop the script above at Step 3 to get an output displayed as shown in the file asyncore_comparison.txt below. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:29 Message: Logged In: YES user_id=80475 Andrew, what this due to your updates or was Martin's loop counter the cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 From noreply at sourceforge.net Sun Sep 26 19:28:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 26 19:28:27 2004 Subject: [ python-Bugs-1034496 ] Configure uses GNU ld flags with non-GNU compilers/linkers Message-ID: Bugs item #1034496, was opened at 2004-09-25 10:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034496&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Drew Schatt (dschatt) Assigned to: Nobody/Anonymous (nobody) Summary: Configure uses GNU ld flags with non-GNU compilers/linkers Initial Comment: I was just attempting to build Python 2.3.4 on Solaris 9, using Sun's Compilers and linkers (/opt/SUNWspro/bin/cc and /usr/ccs/ bin/ld). The configure script correctly determined that I was not using either GNU gcc or GNU ld. However, it continued to put GNU specific variables into the Makefile (specifically, -Wl,). This broke several things, until I manually removed them. The first place it broke was when it created the shared library, which, because of the different ways that Sun's linker and GNU ld handle options, ended up being named "name\=libpython2.3.so.1.0" because Sun's compiler detected two -o flags (the first being in the -Wl,-soname=libpython2.3.so.1.0 -o libpython2.3.so.1.0) - and Sun's linker takes the first -o flag it sees (it helpfully tells you that, though). So... the GNU specific flags need to ONLY be used if the GNU ld/ gcc are being used. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-26 19:28 Message: Logged In: YES user_id=21627 I'm a bit surprised that you are saying that the C compiler has problems with -Wl, options. Atleast in "Sun WorkShop 6 update 1 C 5.2 2000/09/11", the -Wl option is documented for cc, and works fine. Instead, it appears that the system linker does not support the -soname option. However, this option is only used if you build with --enable-shared, which apparently is supported only for GCC on Solaris. So as a work-around, don't use that option. I have now replace -shared with -h in Makefile.pre.in 1.136.6.5 and 1.148, which should fix this bug. Since I don't have SunPRO, I cannot test that scenario. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034496&group_id=5470 From noreply at sourceforge.net Sun Sep 26 19:37:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 26 19:37:38 2004 Subject: [ python-Bugs-1023838 ] Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Message-ID: Bugs item #1023838, was opened at 2004-09-07 19:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Richards (cdgregorr) Assigned to: Nobody/Anonymous (nobody) Summary: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys Initial Comment: While attempting to compile on Solaris 8 64-bit or HPUX 64-bit, Python 2.3.4 has an "error" because LONG_BIT is not defined properly. This error is incorrect on non-glibc systems, and Python compiles fine with it disabled. Here's the incorrect assumption: #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." #endif This should include something to limit it to only glibc systems. - Gregor Richards ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-26 19:37 Message: Logged In: YES user_id=21627 Setting CFLAGS during configure is currently not supported. As a work-around, try setting BASECFLAGS in addition to CFLAGS, or edit the generated Makefile. ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-14 21:14 Message: Logged In: YES user_id=835341 By the way, I ended up making it work with ... export CC="$CC $CFLAGS" export CFLAGS= ./configure However, this should not be necessary. ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-14 21:12 Message: Logged In: YES user_id=835341 export CC="/usr/bin/gcc" export CFLAGS="-m64 -O2" ./configure - Gregor Richards ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 09:55 Message: Logged In: YES user_id=21627 Did you specify CFLAGS during configure? If not, how did the flags get added for 64-bit mode? ---------------------------------------------------------------------- Comment By: Gregor Richards (cdgregorr) Date: 2004-09-13 18:36 Message: Logged In: YES user_id=835341 I managed to track down the problem. Both of these architectures require a cc flag to build in 64-bit mode, but the tests in configure were done without CFLAGS. Thus, they build 32-bit, and the wrong values came out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-07 19:57 Message: Logged In: YES user_id=31435 What are LONG_BIT and SIZEOF_LONG on these platforms? It doesn't matter whether gcc is being used, if LONG_BIT is defined incorrectly for the platform, then it's defined incorrectly period. Read the comment you quoted to see why it doesn't matter whether Python "compiles fine" if you disable this. It's guarding against runtime errors in Python's intobject.c, which needs a correct value for LONG_BIT. Presumably LONG_BIT should be 64 on these boxes, and SIZEOF_LONG should be 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1023838&group_id=5470 From noreply at sourceforge.net Mon Sep 27 03:18:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 03:18:54 2004 Subject: [ python-Bugs-1034277 ] Why does Python link to Foundation? Message-ID: Bugs item #1034277, was opened at 2004-09-24 15:05 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Why does Python link to Foundation? Initial Comment: I can't see any reason for Python to link to Foundation, so I don't think it should. Am I missing something? ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-09-26 21:18 Message: Logged In: YES user_id=139309 mactoolboxglue seems to be the culprit. I don't think linking to Foundation is necessary, but it seems that CoreFoundation is (for now, anyway). locateResourcePy uses CoreFoundation, which is used in the public API implementation of PyMac_GetAppletScriptFile.. however PyMac_GetAppletScriptFile is not used anywhere! I would like to remove it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 From noreply at sourceforge.net Mon Sep 27 03:29:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 03:29:04 2004 Subject: [ python-Bugs-1034277 ] Why does Python link to Foundation? Message-ID: Bugs item #1034277, was opened at 2004-09-24 15:05 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Why does Python link to Foundation? Initial Comment: I can't see any reason for Python to link to Foundation, so I don't think it should. Am I missing something? ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-09-26 21:29 Message: Logged In: YES user_id=139309 Removing those unused functions, we're left with two functions that require CoreServices: PyMac_StrError GetResource HLock HUnlock ReleaseResource PyMac_GetFullPathname FSpMakeFSRef FSMakeFSSpec FSpMakeFSRef FSRefMakePath I think these two functions can safely be refactored so that their functionality comes from elsewhere. Realistically, both of these functions could probably be written in Python anyway (it sure sounds like PyMac_GetFullPathname should be due to the comments) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-09-26 21:18 Message: Logged In: YES user_id=139309 mactoolboxglue seems to be the culprit. I don't think linking to Foundation is necessary, but it seems that CoreFoundation is (for now, anyway). locateResourcePy uses CoreFoundation, which is used in the public API implementation of PyMac_GetAppletScriptFile.. however PyMac_GetAppletScriptFile is not used anywhere! I would like to remove it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 From noreply at sourceforge.net Mon Sep 27 05:45:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 05:46:01 2004 Subject: [ python-Bugs-1034277 ] Why does Python link to Foundation? Message-ID: Bugs item #1034277, was opened at 2004-09-24 15:05 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Why does Python link to Foundation? Initial Comment: I can't see any reason for Python to link to Foundation, so I don't think it should. Am I missing something? ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-09-26 23:45 Message: Logged In: YES user_id=139309 See patch at http://python.org/sf/1035255 ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-09-26 21:29 Message: Logged In: YES user_id=139309 Removing those unused functions, we're left with two functions that require CoreServices: PyMac_StrError GetResource HLock HUnlock ReleaseResource PyMac_GetFullPathname FSpMakeFSRef FSMakeFSSpec FSpMakeFSRef FSRefMakePath I think these two functions can safely be refactored so that their functionality comes from elsewhere. Realistically, both of these functions could probably be written in Python anyway (it sure sounds like PyMac_GetFullPathname should be due to the comments) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-09-26 21:18 Message: Logged In: YES user_id=139309 mactoolboxglue seems to be the culprit. I don't think linking to Foundation is necessary, but it seems that CoreFoundation is (for now, anyway). locateResourcePy uses CoreFoundation, which is used in the public API implementation of PyMac_GetAppletScriptFile.. however PyMac_GetAppletScriptFile is not used anywhere! I would like to remove it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034277&group_id=5470 From noreply at sourceforge.net Mon Sep 27 08:10:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 08:10:42 2004 Subject: [ python-Bugs-1035279 ] hex() and oct() documentation is incorrect Message-ID: Bugs item #1035279, was opened at 2004-09-27 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035279&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: hex() and oct() documentation is incorrect Initial Comment: The documentation for hex() and oct() in the library reference currently still says they return unsigned literals only. With the progress of int/long unification, they no longer do this. hex(-1) now returns "-0x1". This is required so that "eval(hex(-1)) == -1" continues to be true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035279&group_id=5470 From noreply at sourceforge.net Mon Sep 27 10:54:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 10:54:57 2004 Subject: [ python-Bugs-643841 ] New class special method lookup change Message-ID: Bugs item #643841, was opened at 2002-11-26 09:37 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643841&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: New class special method lookup change Initial Comment: The lookup of special methods invoked implicitly by syntax other than explicit instance.attribute changed to *not* use __gettattr__ when normal lookup failed. This is contrary to docs, which consistently say __getattr__ is unchanged. New special method __getattribute__ is also bypassed, contrary to implication of doc-essay. This was reported on c.l.p by Jan Decaluwe using 2.2.2 on Red Hat Linux. On Win98, 2.2.1, I get same behavior (I added test of __getattribute__): class Iold: def __init__(self,ob): self.ob = ob def __getattr__(self,name): return getattr(self.ob,name) class Inew(object): def __init__(self,ob): self.ob = ob def __getattr__(self,name): return getattr(self.ob,name) a = Iold(1) #2 b = Inew(1) #2 a.__add__(1) #2 b.__add__(1) #2 a+1 #2 b+1 #error #TypeError: unsupported operand types for +: 'Inew' and 'int' Inew.__getattribute__ = Inew.__getattr__ b+1 #same error, no loop #TypeError: unsupported operand types for +: 'Inew' and 'int' b.__add__(1) # WARNING starts 'infinite' loop def _(self,other): print 'hello' Inew.__add__ = _ b+1 #prints 'hello', __getattribute__ bypassed. http://python.org/2.2/descrintro.html says: "Note that while in general operator overloading works just as for classic classes, there are some differences. (The biggest one is the lack of support for __coerce__; new-style classes should always use the new-style numeric API, which passes the other operand uncoerced to the __add__ and __radd__ methods, etc.) " Was lookup change meant to be one of differences? "There's a new way of overriding attribute access. The __getattr__ hook, if defined, works the same way as it does for classic classes: it is only called if the regular way of searching for the attribute doesn't find it." But it is different. "But you can now also override __getattribute__, a new operation that is called for all attribute references." Except for implicit special methods. I did not classify discrepancy because I don't know whether interpreter or docs are off. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-27 18:54 Message: Logged In: YES user_id=1038590 FWIW, this is still true for Python 2.4 (i.e. the search for '__add__' by '+' invokes neither __getattr__ nor __getattribute__). The 'infinite loop' is courtesy of the call to 'self.ob' inside __getattr__. Also of interest - int(b) fails with a TypeError, and str(b) returns the generic object representation of b, rather than delegating to the contained object. So it looks like these methods are not invoked when looking up any 'magic methods' recognised by the interpreter. Inspection of PyNumber_Add shows that this is the case - the objects' method pointers are inspected directly at the C level. To me, this looks like a documentation bug. Magic methods are found by checking if the associated slot in the method structure is not NULL, rather than by actually looking for the relevant magic 'attribute'. In order to change the 'implicit' behaviour of the object, it is necessary to change the contents of the underlying method slot - a task which is carried out by type whenever an attribute is set, or when a new instance of type is created. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-11-26 14:25 Message: Logged In: YES user_id=593130 Print-style 'debugging' output provided by Bengt Richter in a follow-up in the c.l.p. thread "Issue with new-style classes and operators" showed that 'a+1' worked because of a __getattr__ call getting '__coerce__' (rather than '__add__') and that 'b+1' did not trigger such a call. So I presume the quoted parenthesized statement about __coerce__ and 'new-style numeric API' was meant to explain as least this part of the change in behavior. However, it is still not clear to me, even after reading the development (2.3a) version of the ref manual, why failure to find '__add__' in 'the usual places' (to quote RefMan 3.3.2 __getattr__ entry) does not trigger a call to __getattr__, nor why the initial attempt to find it did not trigger __getattribute__. The sentence 'For objects x and y, first x.__op__(y) is tried' (3.3.7) implies to me that there is an attempt to find __op__ as an attribute of x. Unless I missed something I should have found, a bit more clarification might be usefully added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643841&group_id=5470 From noreply at sourceforge.net Mon Sep 27 11:46:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 11:46:26 2004 Subject: [ python-Bugs-1034178 ] Can't inherit slots from new-style classes implemented in C Message-ID: Bugs item #1034178, was opened at 2004-09-25 02:33 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034178&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: Can't inherit slots from new-style classes implemented in C Initial Comment: I have a new-style class implemented in C which defines slots (eg. puts a C function pointer in mp_length). It does not create a __len__ entry in the class dictionary. If I sub-class it in Python then the slot is not inherited. The function pointer is copied correctly by inherit_slots() (in typeobject.c). The problem occurs in update_one_slot(). The call to _PyType_Lookup() fails because the slot does not have an entry in the class dictionary. This causes the valid function pointer to be overwritten with the value of "specific" which is 0. The following patch fixes the problem - but I'm not sure it is the correct fix. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-27 19:46 Message: Logged In: YES user_id=1038590 Without seeing the original code, I'm not convinced this is a Python problem. This is due to the fact that inheriting from builtin's and standard library objects defined in C works fine. For instance, inheriting dict's __len__ is shown here: >>> class foo(dict): pass ... >>> len(foo()) 0 >>> foo.__len__ But grep shows the dict source makes no reference to '__len__' directly: [...@localhost src]$ grep -Hc "__len__" Objects/dictobject.c Objects/dictobject.c:0 The way it works is that PyType_Ready generates the appropriate __dict__ entries for all of the special methods that are defined at the C level (i.e. have non-null pointers). If you aren't invoking PyType_Ready before using your class, then it won't work properly. (This invocation is usually made in the C module's initialisation method). See the "Extending and Embedding" docs for all the gory details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034178&group_id=5470 From noreply at sourceforge.net Mon Sep 27 11:58:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 11:58:04 2004 Subject: [ python-Bugs-868845 ] Need unit tests for <...> reprs Message-ID: Bugs item #868845, was opened at 2004-01-02 02:28 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need unit tests for <...> reprs Initial Comment: Samuele Pedroni points out in python-dev that the <...> style reprs of Python objects are not documented, standardized or even consistent (e.g. compare old-style and new-style classes). Yet there is plenty of code out there that for various reasons parses these things or a least depends on what they look like (the parrot benchmark being only the latest example). So it would behoove us to standardize these. An easy way would be unit tests. Any takers? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-27 19:58 Message: Logged In: YES user_id=1038590 Sure. I've been looking for something to do after giving up on finding any more Python-level speed increases for Decimal :) Patch forthcoming in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868845&group_id=5470 From noreply at sourceforge.net Mon Sep 27 13:23:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 13:23:24 2004 Subject: [ python-Bugs-868845 ] Need unit tests for <...> reprs Message-ID: Bugs item #868845, was opened at 2004-01-02 02:28 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Need unit tests for <...> reprs Initial Comment: Samuele Pedroni points out in python-dev that the <...> style reprs of Python objects are not documented, standardized or even consistent (e.g. compare old-style and new-style classes). Yet there is plenty of code out there that for various reasons parses these things or a least depends on what they look like (the parrot benchmark being only the latest example). So it would behoove us to standardize these. An easy way would be unit tests. Any takers? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-27 21:23 Message: Logged In: YES user_id=1038590 Although, now that I look at the relevant py-dev threads, I'm not entirely sure what needs to be standardised. Consider the following: __main__.foo <__main__.foo instance at 0xf6f8baac> > <__main__.bar object at 0xf6f8baec> > Which is the result of: from array import array class foo: def x(): pass class bar(object): def x(): pass def func(): pass for obj in array, dict, foo, foo(), foo.x, foo().x, bar, bar(), bar.x, bar().x, func: print obj ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-27 19:58 Message: Logged In: YES user_id=1038590 Sure. I've been looking for something to do after giving up on finding any more Python-level speed increases for Decimal :) Patch forthcoming in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868845&group_id=5470 From noreply at sourceforge.net Mon Sep 27 16:42:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 18:02:22 2004 Subject: [ python-Bugs-1019882 ] hotshot start / stop stats bug Message-ID: Bugs item #1019882, was opened at 2004-08-31 14:06 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019882&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: hotshot start / stop stats bug Initial Comment: Hotshot has a bug that manifests when using start/stop instead of run(), however it appears to only occur in the interactive interpreter or in an embedded application. If you run the attached program like "python hotshotbug.py" it works just fine. However, if you start an interactive session and paste each line one by one into the shell, you get the following exception: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/local/lib/python2.3/hotshot/stats.py", line 29, in load for event in log: File "/usr/local/lib/python2.3/hotshot/log.py", line 110, in next return what, self._pop(), tdelta IndexError: pop from empty list We discovered this when trying to profile an embedded application which doesn't have a single entrypoint suitable for run(). Unfortunately, I can't provide that application, but it shouldn't matter, since the interpreter crash is the same. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:42 Message: Logged In: YES user_id=12800 Could this be related to 900092? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019882&group_id=5470 From noreply at sourceforge.net Mon Sep 27 16:41:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 19:02:31 2004 Subject: [ python-Bugs-900092 ] hotshot.stats.load Message-ID: Bugs item #900092, was opened at 2004-02-19 03:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: hotshot.stats.load Initial Comment: trying to do a hotshot.stats.load("myprofiling_file.prof") fails with assertionerror assert not self._stack python 2.3.2 on WinXP ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 10:41 Message: Logged In: YES user_id=12800 Could this be related to 1019882? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 18:00 Message: Logged In: YES user_id=469548 Hmm, the file was too big, even though it was compressed. I've uploaded it to http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2 now. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 17:58 Message: Logged In: YES user_id=469548 While the original report isn't very useful, I've ran into this problem multiple times as well. I can reproduce it using the attached profile file (compressed because of the large size) and the following console session: Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hotshot.stats >>> stats = hotshot.stats.load('roundup.prof') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load assert not self._stack AssertionError >>> I'm not sure who's baby hotshot really is, so I'm leaving this unassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470 From noreply at sourceforge.net Mon Sep 27 19:55:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 19:55:21 2004 Subject: [ python-Bugs-1010098 ] CPU usage shoots up with asyncore Message-ID: Bugs item #1010098, was opened at 2004-08-16 15:54 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Thomas (thomasabc) Assigned to: A.M. Kuchling (akuchling) Summary: CPU usage shoots up with asyncore Initial Comment: The CPU usage of a python application program using asyncore.py shoot up to 99% under Python 2.4a1. After a comparison, it was found out that the same program ran without such high CPU usage under Python 2.3.3 A simple couple of programs to narrow down the problem showed that a single loop() was accompanied by a large number of poll() with 2.4a1, whereas a single loop() had only 3 calls to poll() with 2.3.3. Please let me know if there is anything else I can do for you to analyse. A couple of python scripts are attached in a zip file for you as below: - Summary of the test scripts With these scripts, the test attempts to identify what function calls are called that might explain the high CPU usage observed. asyncore_test.py: Taken from the Python Library Reference 11.24.2 asynchat Example, the test program starts a server process to simulate client request process. http_test.py: This program simply establishes connection to the server and closes after 10 seconds. - Procedure 1. Start asyncore_test.py 2. Start http_test.py 3. Stop asyncore_test.py ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-09-27 17:55 Message: Logged In: YES user_id=4771 Experimenting a bit, I found out that using asynchat.py from Python 2.3.3 in an otherwise CVS HEAD Python solves the problem. The problem was introduced in this file in revision 1.22 by Raymond: "Use collection.deque() instead of a list for a FIFO queue." The problem is at line 261: "return self.list == []" which is a correct way to check if a list is empty, but not if a deque is empty! Fix checked in as asynchat.py:1.25. The same bug doesn't seem to be present anywhere else. A few usages of deques in the standard library seem unjustified: in shlex.py, items are only added or removed at the left. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-21 23:01 Message: Logged In: YES user_id=31435 I can confirm the primary symptom on WinXP. For the 10 seconds http_test.py runs, CPU is nailed to the wall under current CVS Python, but is a trickle under 2.3.4. asyncore appears to be irrelevant. "The problem" is that the socket associated with __main__.http_request_handler always comes back in the w set from select.select() under current Python, but the select times out under 2.3.4. More detail: under current Python, dumping some prints in asyncore.poll() delivers a huge number of repetitions of this info: socket map is {1940: <__main__.http_request_handler connected 127.0.0.1:3455 at 0x9da800>, 1948: <__main__.AsyncHTTPServer listening :40004 at 0x9d7fa8>} r, w, e passed in is [1940, 1948] [1940, 1948] [1940, 1948] r, w, e returned is [], [1940], [] Under 2.3.4, there are only a few lines of output total -- select() doesn't believe the sockets passed to it are ready to read or ready to write. So the difference is in socket behavior, or in how the layers around asyncore here are using sockets. ---------------------------------------------------------------------- Comment By: Thomas (thomasabc) Date: 2004-08-20 10:05 Message: Logged In: YES user_id=1104845 Sorry, just to let you know that you press Ctrl+C to stop the script above at Step 3 to get an output displayed as shown in the file asyncore_comparison.txt below. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 17:29 Message: Logged In: YES user_id=80475 Andrew, what this due to your updates or was Martin's loop counter the cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 From noreply at sourceforge.net Mon Sep 27 21:55:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 21:55:06 2004 Subject: [ python-Bugs-952953 ] execve rejects empty argument list Message-ID: Bugs item #952953, was opened at 2004-05-13 00:54 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952953&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: newsham (newsham) Assigned to: Nobody/Anonymous (nobody) Summary: execve rejects empty argument list Initial Comment: The exec* family of calls in the os package does not allow an empty list of arguments to be passed in. Passing is an empty list (ie. allow argv[0] to be NULL and argc to be zero) is rarely desired, but perfectly legal. Verify by: import os os.execve("/bin/ls", [], {}) Tim N. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-09-27 19:55 Message: Logged In: YES user_id=4771 Applied patch. ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-14 23:53 Message: Logged In: YES user_id=1094771 a patch has been submitted (# 1009075) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:48 Message: Logged In: YES user_id=6656 I think you'll need to supply a patch to have any hope of this changing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952953&group_id=5470 From noreply at sourceforge.net Mon Sep 27 22:06:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 22:06:40 2004 Subject: [ python-Bugs-1035703 ] distutils.util.get_platform() should include sys.version[:2] Message-ID: Bugs item #1035703, was opened at 2004-09-27 16:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035703&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.util.get_platform() should include sys.version[:2] Initial Comment: When dealing with systems that have multiple versions of Python installed, it would be nice if distutils.util.get_platform() included the major python version (sys.version[:3]) so that you could do: python2.3 setup.py install python2.4 setup.py install and expect everything to typically work correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035703&group_id=5470 From noreply at sourceforge.net Mon Sep 27 22:07:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 22:07:10 2004 Subject: [ python-Bugs-1035703 ] distutils.util.get_platform() should include sys.version[:3] Message-ID: Bugs item #1035703, was opened at 2004-09-27 16:06 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035703&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) >Summary: distutils.util.get_platform() should include sys.version[:3] Initial Comment: When dealing with systems that have multiple versions of Python installed, it would be nice if distutils.util.get_platform() included the major python version (sys.version[:3]) so that you could do: python2.3 setup.py install python2.4 setup.py install and expect everything to typically work correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035703&group_id=5470 From noreply at sourceforge.net Tue Sep 28 04:28:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 04:28:48 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-27 22:28 Message: Logged In: YES user_id=31435 Yup, this is fixed as far as I'm concerned, so closing it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 13:50 Message: Logged In: YES user_id=80475 Tim, can this be marked as fixed and closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 23:25 Message: Logged In: YES user_id=31435 Zope3's problem w/ asyncore appears to be fixed. Thanks! WRT > Therefore, I think the 'if is_r or is_w' logic is necessary. I expect you're right. I think I had vaguely in mind that "the usual" implementation of fdsets represents them as bit vectors, so that redundancy wouldn't hurt. But that's not the only part of the story, and I overlooked that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 10:08 Message: Logged In: YES user_id=11375 Original patch committed as rev. 1.61 of asyncore.py. I'm leaving the bug open until Tim (or someone) reports that the problem is fixed. poll2 (the one that uses select.poll()) should automatically remove objects for which POLLNVAL is set -- that's what the error means, after all. I'll worry about that after 2.3alpha3 is released. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-09-01 09:32 Message: Logged In: YES user_id=11375 'e = r+w' means 'e' can contain the same descriptor twice, if it's both readable and writable, and I think this matters. Duplicate fd's don't cause a problem with the select() system call itself, but the return value from select.select() would include the file descriptor twice. (I've attached a test program that demonstrates this for readable fds.) Therefore, I think the 'if is_r or is_w' logic is necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:49 Message: Logged In: YES user_id=31435 Logic similar to the logic in the patch worked for me when I tried it. Suggest it would be faster and clearer to just add e = r + w to the 2.3 asyncore poll(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 12:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Tue Sep 28 04:33:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 04:33:48 2004 Subject: [ python-Bugs-1033038 ] Misleading error message in random.choice Message-ID: Bugs item #1033038, was opened at 2004-09-22 19:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) >Assigned to: Raymond Hettinger (rhettinger) Summary: Misleading error message in random.choice Initial Comment: Giving random.choice(seq) an empty sequence leads to a misleading error message, as per this example: >>> import random; random.choice([]) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 231, in choice return seq[int(self.random() * len(seq))] IndexError: list index out of range A simple fix is to "assert len(seq) > 0" in the choice method. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-27 22:33 Message: Logged In: YES user_id=31435 No, I don't want to change this either. choice() is one of the few library functions where speed matters a lot, and checking for invalid arguments *just* to give a wordier error message would be a losing tradeoff because of that. If you want to add a line to the docs, that's cool, but not "If the sequence is empty, raises TypeError". That's a bad idea because it actually raises IndexError . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 13:46 Message: Logged In: YES user_id=80475 Tim, I'm -1 on this one. What do you think? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-22 20:05 Message: Logged In: YES user_id=80475 Perhaps I've been using it for too long, but I do not find the error message to misleading. Also, I like having this method as simple and lightweight as possible though it may be worthwhile to add a line to the docs, "If the sequence is emtpy, raises a TypeError." If someone accepts this request, it should implemented as a try/except rather than an assertion. That approach would also let you catch TypeErrors raised is the argument doesn't define __len__ and __getitem__, for example: random.choice(set('abc')) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 From noreply at sourceforge.net Tue Sep 28 05:04:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 05:04:41 2004 Subject: [ python-Bugs-1033038 ] Misleading error message in random.choice Message-ID: Bugs item #1033038, was opened at 2004-09-22 18:48 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Raymond Hettinger (rhettinger) Summary: Misleading error message in random.choice Initial Comment: Giving random.choice(seq) an empty sequence leads to a misleading error message, as per this example: >>> import random; random.choice([]) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 231, in choice return seq[int(self.random() * len(seq))] IndexError: list index out of range A simple fix is to "assert len(seq) > 0" in the choice method. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-27 22:04 Message: Logged In: YES user_id=80475 Added a line to the docs: Doc/lib/librandom.tex 1.38 Marking as closed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-27 21:33 Message: Logged In: YES user_id=31435 No, I don't want to change this either. choice() is one of the few library functions where speed matters a lot, and checking for invalid arguments *just* to give a wordier error message would be a losing tradeoff because of that. If you want to add a line to the docs, that's cool, but not "If the sequence is empty, raises TypeError". That's a bad idea because it actually raises IndexError . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 12:46 Message: Logged In: YES user_id=80475 Tim, I'm -1 on this one. What do you think? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-22 19:05 Message: Logged In: YES user_id=80475 Perhaps I've been using it for too long, but I do not find the error message to misleading. Also, I like having this method as simple and lightweight as possible though it may be worthwhile to add a line to the docs, "If the sequence is emtpy, raises a TypeError." If someone accepts this request, it should implemented as a try/except rather than an assertion. That approach would also let you catch TypeErrors raised is the argument doesn't define __len__ and __getitem__, for example: random.choice(set('abc')) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033038&group_id=5470 From noreply at sourceforge.net Tue Sep 28 06:56:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 06:56:39 2004 Subject: [ python-Bugs-979924 ] email.Message.Message.__getitem__ doc string wrong Message-ID: Bugs item #979924, was opened at 2004-06-25 14:52 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979924&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message.Message.__getitem__ doc string wrong Initial Comment: The doc string for email.Message.Message.__getitem__ references a "getall" method. There is no such method. It should refer to the "get_all" method instead. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-28 00:56 Message: Logged In: YES user_id=12800 1.32.10.5 for Python 2.3. I've also fixed this for Python 2.4, but I'm going to check this in with a bunch of other email package changes I'm working on. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-17 08:31 Message: Logged In: YES user_id=55188 I think this may resolved by Barry. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979924&group_id=5470 From noreply at sourceforge.net Tue Sep 28 21:50:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 21:50:18 2004 Subject: [ python-Bugs-1036490 ] unicode strings cannot be dictionary keys Message-ID: Bugs item #1036490, was opened at 2004-09-28 21:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036490&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Morten Kjeldgaard (mok0) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode strings cannot be dictionary keys Initial Comment: Lots of modules return unicode strings, for example the xml parser. There is no reason why you shouldn't be able to use a unicode string as key in a dictionary, shelve or database lookup. I think this is more a bug than a feature, since having to make sure what type your keys are makes the code bloated and ugly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036490&group_id=5470 From noreply at sourceforge.net Tue Sep 28 21:59:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 21:59:26 2004 Subject: [ python-Bugs-1036506 ] Email module's feed parser Message-ID: Bugs item #1036506, was opened at 2004-09-28 14:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036506&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: Email module's feed parser Initial Comment: Barry asked me to open this so as to attach the message. If the feed parser parsers a message that has a content-type of multipart/ but which contains only a single part, the resulting Message object is internally inconsistent: get_main_type() returns "multipart" but is_multipart() returns False. I don't think that this is actually a bug because figuring out the right content-type to assign would require groveling through the payload with a bunch of messy heuristics. It seems to me that the standard library isn't the place for messy heuristics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036506&group_id=5470 From noreply at sourceforge.net Tue Sep 28 22:00:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 22:00:43 2004 Subject: [ python-Bugs-1036506 ] Email module's feed parser Message-ID: Bugs item #1036506, was opened at 2004-09-28 14:59 Message generated for change (Settings changed) made by mdcowles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036506&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Email module's feed parser Initial Comment: Barry asked me to open this so as to attach the message. If the feed parser parsers a message that has a content-type of multipart/ but which contains only a single part, the resulting Message object is internally inconsistent: get_main_type() returns "multipart" but is_multipart() returns False. I don't think that this is actually a bug because figuring out the right content-type to assign would require groveling through the payload with a bunch of messy heuristics. It seems to me that the standard library isn't the place for messy heuristics. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036506&group_id=5470 From noreply at sourceforge.net Tue Sep 28 16:25:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 22:04:41 2004 Subject: [ python-Bugs-1011380 ] Make GIL acquire/release functions noops if PyEval_Init Message-ID: Bugs item #1011380, was opened at 2004-08-18 13:07 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011380&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) >Summary: Make GIL acquire/release functions noops if PyEval_Init Initial Comment: The patch makes GIL acquire/release functions idempotent if PyEval_InitThreads hasn't been called. Motivation for this change can be found in my post to python-dev, here: http://mail.python.org/pipermail/python-dev/2004-August/047870.html http://mail.python.org/pipermail/python-dev/2004-August/047871.html Some feedback here: http://mail.python.org/pipermail/python-dev/2004-August/047949.html ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2004-09-28 15:25 Message: Logged In: YES user_id=908 Can someone please take a look at this patch? It's fairly simple, but very important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011380&group_id=5470 From noreply at sourceforge.net Tue Sep 28 22:35:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 22:35:45 2004 Subject: [ python-Bugs-1036490 ] unicode strings cannot be dictionary keys Message-ID: Bugs item #1036490, was opened at 2004-09-28 15:50 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036490&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Morten Kjeldgaard (mok0) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode strings cannot be dictionary keys Initial Comment: Lots of modules return unicode strings, for example the xml parser. There is no reason why you shouldn't be able to use a unicode string as key in a dictionary, shelve or database lookup. I think this is more a bug than a feature, since having to make sure what type your keys are makes the code bloated and ugly. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-09-28 16:35 Message: Logged In: YES user_id=7733 Unicode strings work as dictionary keys for me, in both Python 2.3.3 and 2.4a3. Are you sure of your assertion? Please provide some evidence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036490&group_id=5470 From noreply at sourceforge.net Tue Sep 28 22:58:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 22:58:47 2004 Subject: [ python-Bugs-1036490 ] unicode strings cannot be dictionary keys Message-ID: Bugs item #1036490, was opened at 2004-09-28 21:50 Message generated for change (Comment added) made by mok0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036490&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Morten Kjeldgaard (mok0) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode strings cannot be dictionary keys Initial Comment: Lots of modules return unicode strings, for example the xml parser. There is no reason why you shouldn't be able to use a unicode string as key in a dictionary, shelve or database lookup. I think this is more a bug than a feature, since having to make sure what type your keys are makes the code bloated and ugly. ---------------------------------------------------------------------- >Comment By: Morten Kjeldgaard (mok0) Date: 2004-09-28 22:58 Message: Logged In: YES user_id=42755 You are right, unicode strings work in dictionaries. I should have checked, sorry. However, they don't work in shelves, as the attached script will demonstrate. You get a type error: Traceback (most recent call last): File "fail.py", line 7, in ? x[a] = "arrrghhh" File "/usr/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/lib/python2.3/site-packages/__init__.py", line 120, in __setitem__ TypeError: String or Integer object expected for key, unicode found I am using Python 2.3.3 on Linux ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-09-28 22:35 Message: Logged In: YES user_id=7733 Unicode strings work as dictionary keys for me, in both Python 2.3.3 and 2.4a3. Are you sure of your assertion? Please provide some evidence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036490&group_id=5470 From noreply at sourceforge.net Tue Sep 28 23:22:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 23:22:56 2004 Subject: [ python-Bugs-1036506 ] Email module's feed parser Message-ID: Bugs item #1036506, was opened at 2004-09-28 15:59 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036506&group_id=5470 Category: Python Library Group: Not a Bug >Status: Closed Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Email module's feed parser Initial Comment: Barry asked me to open this so as to attach the message. If the feed parser parsers a message that has a content-type of multipart/ but which contains only a single part, the resulting Message object is internally inconsistent: get_main_type() returns "multipart" but is_multipart() returns False. I don't think that this is actually a bug because figuring out the right content-type to assign would require groveling through the payload with a bunch of messy heuristics. It seems to me that the standard library isn't the place for messy heuristics. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-28 17:22 Message: Logged In: YES user_id=12800 Integrated into test suite (soon to be checked in). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036506&group_id=5470 From noreply at sourceforge.net Tue Sep 28 23:48:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 23:48:06 2004 Subject: [ python-Feature Requests-1036490 ] Extend Shelf to support unicode keys Message-ID: Feature Requests item #1036490, was opened at 2004-09-28 15:50 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1036490&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morten Kjeldgaard (mok0) >Assigned to: Nobody/Anonymous (nobody) >Summary: Extend Shelf to support unicode keys Initial Comment: Lots of modules return unicode strings, for example the xml parser. There is no reason why you shouldn't be able to use a unicode string as key in a dictionary, shelve or database lookup. I think this is more a bug than a feature, since having to make sure what type your keys are makes the code bloated and ugly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-28 17:48 Message: Logged In: YES user_id=31435 Moved to the Feature Request tracker, and changed the summary to something more accurate. The restriction to string keys is documented, and the code is functioning as documented. The restriction is hard to lift because the underlying database technologies (gdbm, bsddb) require string keys. I suppose Shelf could encode all incoming keys via utf-8, in every method taking a key argument, and decode again in all ways of getting keys out, but that wouldn't be backward compatible. Unassigned Marc-Andre since I doubt he's going to do something about this. ---------------------------------------------------------------------- Comment By: Morten Kjeldgaard (mok0) Date: 2004-09-28 16:58 Message: Logged In: YES user_id=42755 You are right, unicode strings work in dictionaries. I should have checked, sorry. However, they don't work in shelves, as the attached script will demonstrate. You get a type error: Traceback (most recent call last): File "fail.py", line 7, in ? x[a] = "arrrghhh" File "/usr/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/lib/python2.3/site-packages/__init__.py", line 120, in __setitem__ TypeError: String or Integer object expected for key, unicode found I am using Python 2.3.3 on Linux ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-09-28 16:35 Message: Logged In: YES user_id=7733 Unicode strings work as dictionary keys for me, in both Python 2.3.3 and 2.4a3. Are you sure of your assertion? Please provide some evidence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1036490&group_id=5470 From noreply at sourceforge.net Tue Sep 28 23:53:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 23:53:44 2004 Subject: [ python-Feature Requests-1036490 ] Extend Shelf to support unicode keys Message-ID: Feature Requests item #1036490, was opened at 2004-09-28 15:50 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1036490&group_id=5470 >Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morten Kjeldgaard (mok0) Assigned to: Nobody/Anonymous (nobody) Summary: Extend Shelf to support unicode keys Initial Comment: Lots of modules return unicode strings, for example the xml parser. There is no reason why you shouldn't be able to use a unicode string as key in a dictionary, shelve or database lookup. I think this is more a bug than a feature, since having to make sure what type your keys are makes the code bloated and ugly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-28 17:53 Message: Logged In: YES user_id=31435 Reset the Category to Unicode; SF lost it on the way to the Feature tracker. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-28 17:48 Message: Logged In: YES user_id=31435 Moved to the Feature Request tracker, and changed the summary to something more accurate. The restriction to string keys is documented, and the code is functioning as documented. The restriction is hard to lift because the underlying database technologies (gdbm, bsddb) require string keys. I suppose Shelf could encode all incoming keys via utf-8, in every method taking a key argument, and decode again in all ways of getting keys out, but that wouldn't be backward compatible. Unassigned Marc-Andre since I doubt he's going to do something about this. ---------------------------------------------------------------------- Comment By: Morten Kjeldgaard (mok0) Date: 2004-09-28 16:58 Message: Logged In: YES user_id=42755 You are right, unicode strings work in dictionaries. I should have checked, sorry. However, they don't work in shelves, as the attached script will demonstrate. You get a type error: Traceback (most recent call last): File "fail.py", line 7, in ? x[a] = "arrrghhh" File "/usr/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/lib/python2.3/site-packages/__init__.py", line 120, in __setitem__ TypeError: String or Integer object expected for key, unicode found I am using Python 2.3.3 on Linux ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-09-28 16:35 Message: Logged In: YES user_id=7733 Unicode strings work as dictionary keys for me, in both Python 2.3.3 and 2.4a3. Are you sure of your assertion? Please provide some evidence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1036490&group_id=5470 From noreply at sourceforge.net Tue Sep 28 20:35:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 00:03:18 2004 Subject: [ python-Bugs-1036406 ] Tix.Grid widgets not implemented yet Message-ID: Bugs item #1036406, was opened at 2004-09-28 21:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036406&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. L?wis (loewis) Summary: Tix.Grid widgets not implemented yet Initial Comment: This code fails at the .pack method (.grid, .place too): >>> import Tix >>> r=Tix.Tk() >>> g=Tix.Grid() >>> g.pack() Traceback (most recent call last): File "", line 1, in ? File "d:\PY.24\lib\lib-tk\Tkinter.py", line 1692, in pack_configure self.tk.call( _tkinter.TclError: bad window path name ".8257088" Tix Grids work though as shown here: >>> r.tk.call('tixGrid', '.g1') '.g1' >>> r.tk.call('pack', '.g1') '' >>> r.tk.call('.g1', 'set', '0', '0', '-text', 'hello!') '' I intend to supply a patch, but I need to first understand better how Tkinter works (and therefore Tix.py); I create a bug so that anyone willing might help provide Python users with an often requested widget. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036406&group_id=5470 From noreply at sourceforge.net Wed Sep 29 00:42:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 00:42:48 2004 Subject: [ python-Bugs-1036626 ] file.next() info hidden Message-ID: Bugs item #1036626, was opened at 2004-09-28 17:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036626&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: file.next() info hidden Initial Comment: (A.M. Kuchling told me to post this bug report.) In section 2.3.8, "File Objects", of the Python Library Reference, the following section is given for file.next(): << In order to make a for loop the most efficient way of looping over the lines of a file (a very common operation), the next() method uses a hidden read-ahead buffer. As a consequence of using a read-ahead buffer, combining next() with other file methods (like readline()) does not work right. >> This information is necessary for anyone who mixes "for line in file:" with read()/tell()/etc. However, in the statement "for line in file:", next() is called implicitly, and therefore it may not occur to the programmer to find the information there. Therefore the documentation should be reorganized. One solution is to have the read()/tell()/etc. methods refer to the above section. i.e. "Don't use this method with next() or 'for line in file:'; see next()." A second solution is to move the above section to before the methods section (i.e. after the second paragraph after the 2.3.8 header), and to mention 'for line in file:'. i.e. "As a consequence of using a read-ahead buffer, combining next() or 'for line in file:' with other file methods (like readline()) does not work right." (Also, saying "with other file methods (like readline())" is too vague. IMHO it should specify which ones not to use. That's debatable though.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036626&group_id=5470 From noreply at sourceforge.net Wed Sep 29 04:56:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 04:56:30 2004 Subject: [ python-Bugs-1032615 ] Odd behavior with unicode.translate on OSX. Message-ID: Bugs item #1032615, was opened at 2004-09-22 15:00 Message generated for change (Comment added) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 Category: Unicode Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: M.-A. Lemburg (lemburg) Summary: Odd behavior with unicode.translate on OSX. Initial Comment: d = {ord('f'): 'eff '} for i in range(100): ....s = u'f' * i ....print i ....s.translate(d) On my Panther laptop, that fails at i=25 with a MemoryError: *** malloc: vm_allocate(size=1677725696) failed (error code=3) *** malloc[2346]: error: Can't allocate region Traceback (most recent call last): ..File "", line 4, in ? MemoryError It works fine on the Linux and BSD boxes I was able to test on, though. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2004-09-29 04:56 Message: Logged In: YES user_id=858364 I can reproduce this on panther with python 2.3 (Apple Computer, Inc. build 1495). However, with the current 2.4 CVS head (as of 29 Sept) compiled on the same computer, this bug is gone. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-22 19:23 Message: Logged In: YES user_id=89016 This is probably a duplicate of bug 828737 ("unicode translate leaks memory"), which should be fixed in the current version 2.3.4. Which version of Python are you using? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2004-09-22 15:10 Message: Logged In: YES user_id=99508 Oops, that 'eff ' should be u'eff ', obviously. Sorry about that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 From noreply at sourceforge.net Wed Sep 29 05:21:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 05:21:19 2004 Subject: [ python-Bugs-1036752 ] printf() in dynload_shlib.c should be PySys_WriteStderr Message-ID: Bugs item #1036752, was opened at 2004-09-28 23:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036752&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: printf() in dynload_shlib.c should be PySys_WriteStderr Initial Comment: Line 116 of dist/src/Python/dynload_shlib.c contains a printf() guarded by a Py_VerboseFlag. This should be a PySys_WriteStderr instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036752&group_id=5470 From noreply at sourceforge.net Wed Sep 29 06:27:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 06:28:02 2004 Subject: [ python-Bugs-1032395 ] idle -n crashes Message-ID: Bugs item #1032395, was opened at 2004-09-22 02:18 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032395&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed >Priority: 6 Submitted By: Matthias Klose (doko) >Assigned to: Kurt B. Kaiser (kbk) Summary: idle -n crashes Initial Comment: [forwarded from http://bugs.debian.org/272796] $ idle -n (Tk window appears) (Some traceback in red?) (Tk window disappears) screenshot appended. bug submitter writes that idle -n in Windows works (not sure, if he tested 2.3.x or 2.4). idle from 2.4a0 works ok. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-09-28 23:27 Message: Logged In: YES user_id=149084 PyShell rev 1.81.4.4 Bug exhibits in release23-maint only. Debian is using unreleased code from CVS, I neglected testing for -n switch when I checked in 1.81.4.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032395&group_id=5470 From noreply at sourceforge.net Wed Sep 29 06:33:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 06:33:16 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 03:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 2 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-09-28 23:33 Message: Logged In: YES user_id=149084 No further info from OP, close as works-for-me ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-29 17:21 Message: Logged In: YES user_id=149084 I can't reproduce this on WinXP Pro SP1. I suspect it's your hardware or Win installation. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-17 02:23 Message: Logged In: YES user_id=358087 Same thing, it hangs after about 2 hours. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 01:40 Message: Logged In: YES user_id=149084 um, run win32 IDLE and cygwin IDLE at the same time? What happens when you run win32 IDLE without cygwin IDLE? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-16 04:24 Message: Logged In: YES user_id=358087 It hangs even if I don't do anything and even without screen saver. Seems to be a problem in Tk since if I run both win32 IDLE and cygwin IDLE both hang. If I run only cygwin IDLE it's OK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:55 Message: Logged In: YES user_id=149084 If you just start IDLE (shell window only) and don't do anything, does it always hang in two hours? If so, /please/ try this without your screen saver. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 02:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 03:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 04:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 03:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Wed Sep 29 12:42:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 12:42:31 2004 Subject: [ python-Bugs-1032615 ] Odd behavior with unicode.translate on OSX. Message-ID: Bugs item #1032615, was opened at 2004-09-22 15:00 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 Category: Unicode Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: M.-A. Lemburg (lemburg) Summary: Odd behavior with unicode.translate on OSX. Initial Comment: d = {ord('f'): 'eff '} for i in range(100): ....s = u'f' * i ....print i ....s.translate(d) On my Panther laptop, that fails at i=25 with a MemoryError: *** malloc: vm_allocate(size=1677725696) failed (error code=3) *** malloc[2346]: error: Can't allocate region Traceback (most recent call last): ..File "", line 4, in ? MemoryError It works fine on the Linux and BSD boxes I was able to test on, though. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-09-29 12:42 Message: Logged In: YES user_id=89016 Thanks for the check, closing the report. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2004-09-29 04:56 Message: Logged In: YES user_id=858364 I can reproduce this on panther with python 2.3 (Apple Computer, Inc. build 1495). However, with the current 2.4 CVS head (as of 29 Sept) compiled on the same computer, this bug is gone. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-22 19:23 Message: Logged In: YES user_id=89016 This is probably a duplicate of bug 828737 ("unicode translate leaks memory"), which should be fixed in the current version 2.3.4. Which version of Python are you using? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2004-09-22 15:10 Message: Logged In: YES user_id=99508 Oops, that 'eff ' should be u'eff ', obviously. Sorry about that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032615&group_id=5470 From noreply at sourceforge.net Wed Sep 29 20:10:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 00:02:57 2004 Subject: [ python-Bugs-1034178 ] Can't inherit slots from new-style classes implemented in C Message-ID: Bugs item #1034178, was opened at 2004-09-24 17:33 Message generated for change (Comment added) made by philthompson10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034178&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Phil Thompson (philthompson10) Assigned to: Nobody/Anonymous (nobody) Summary: Can't inherit slots from new-style classes implemented in C Initial Comment: I have a new-style class implemented in C which defines slots (eg. puts a C function pointer in mp_length). It does not create a __len__ entry in the class dictionary. If I sub-class it in Python then the slot is not inherited. The function pointer is copied correctly by inherit_slots() (in typeobject.c). The problem occurs in update_one_slot(). The call to _PyType_Lookup() fails because the slot does not have an entry in the class dictionary. This causes the valid function pointer to be overwritten with the value of "specific" which is 0. The following patch fixes the problem - but I'm not sure it is the correct fix. ---------------------------------------------------------------------- >Comment By: Phil Thompson (philthompson10) Date: 2004-09-29 19:10 Message: Logged In: YES user_id=1105728 Yes, it's a bug in my code. The problem was that PyType_Ready() was being called too soon (rather than not at all). I needed to do some initialisation before PyType_Ready() was called and moving it from the tp_new slot to the tp_alloc slot solved. Apologies for the premature report. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-27 10:46 Message: Logged In: YES user_id=1038590 Without seeing the original code, I'm not convinced this is a Python problem. This is due to the fact that inheriting from builtin's and standard library objects defined in C works fine. For instance, inheriting dict's __len__ is shown here: >>> class foo(dict): pass ... >>> len(foo()) 0 >>> foo.__len__ But grep shows the dict source makes no reference to '__len__' directly: [...@localhost src]$ grep -Hc "__len__" Objects/dictobject.c Objects/dictobject.c:0 The way it works is that PyType_Ready generates the appropriate __dict__ entries for all of the special methods that are defined at the C level (i.e. have non-null pointers). If you aren't invoking PyType_Ready before using your class, then it won't work properly. (This invocation is usually made in the C module's initialisation method). See the "Extending and Embedding" docs for all the gory details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1034178&group_id=5470 From noreply at sourceforge.net Thu Sep 30 01:36:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 01:36:24 2004 Subject: [ python-Bugs-1037373 ] len(str(x)) in decimal.py is not Python 2.3 compatible Message-ID: Bugs item #1037373, was opened at 2004-09-30 09:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: len(str(x)) in decimal.py is not Python 2.3 compatible Initial Comment: One of the stated goals of decimal.py is to remain 2.3 compatible. This is not currently the case, as the len(str(x)) trick I used to determine the 'number of digits in an integer' gives the wrong answer for long integers in Python 2.3 (there is an extra 'L' on the end). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 From noreply at sourceforge.net Thu Sep 30 02:34:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 02:34:37 2004 Subject: [ python-Bugs-1037373 ] len(str(x)) in decimal.py is not Python 2.3 compatible Message-ID: Bugs item #1037373, was opened at 2004-09-29 18:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: len(str(x)) in decimal.py is not Python 2.3 compatible Initial Comment: One of the stated goals of decimal.py is to remain 2.3 compatible. This is not currently the case, as the len(str(x)) trick I used to determine the 'number of digits in an integer' gives the wrong answer for long integers in Python 2.3 (there is an extra 'L' on the end). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-29 19:34 Message: Logged In: YES user_id=80475 Check again. str(123L) automatically drops the L repr(123L) keeps it. I had run the decimal tests on Py2.3 without exception. So, please reverify your claim. If valid, show an example where it doesn't work, add that example as a test case, and submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 From noreply at sourceforge.net Thu Sep 30 02:48:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 02:48:54 2004 Subject: [ python-Bugs-1036752 ] printf() in dynload_shlib.c should be PySys_WriteStderr Message-ID: Bugs item #1036752, was opened at 2004-09-28 22:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036752&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Martin v. L?wis (loewis) Summary: printf() in dynload_shlib.c should be PySys_WriteStderr Initial Comment: Line 116 of dist/src/Python/dynload_shlib.c contains a printf() guarded by a Py_VerboseFlag. This should be a PySys_WriteStderr instead. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-29 19:48 Message: Logged In: YES user_id=80475 Martin, I believe this is your code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036752&group_id=5470 From noreply at sourceforge.net Thu Sep 30 02:59:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 02:59:18 2004 Subject: [ python-Bugs-1035279 ] hex() and oct() documentation is incorrect Message-ID: Bugs item #1035279, was opened at 2004-09-27 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035279&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: hex() and oct() documentation is incorrect Initial Comment: The documentation for hex() and oct() in the library reference currently still says they return unsigned literals only. With the progress of int/long unification, they no longer do this. hex(-1) now returns "-0x1". This is required so that "eval(hex(-1)) == -1" continues to be true. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-29 19:59 Message: Logged In: YES user_id=80475 \versionchanged{Formerly only returned an unsigned literal.]{2.4} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1035279&group_id=5470 From noreply at sourceforge.net Thu Sep 30 03:02:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 03:03:01 2004 Subject: [ python-Bugs-1030499 ] os.path.join() does not raise TypeError Message-ID: Bugs item #1030499, was opened at 2004-09-18 18:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030499&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pierre Fortin (pfortin) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.join() does not raise TypeError Initial Comment: Within os and os.path, os.path.join() appears to be the only function which fails to indicate a TypeError. This was found inadvertently with: def foo(*args): ... return os.path.join(args) # note the missing "*" Calling the function with: foo('a','b') returns: ('a','b') Other os & os.path functions return TypeError in this situation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-29 20:02 Message: Logged In: YES user_id=80475 I'm -0 on changing this. The code is already complex and spread across multiple files. It's absence of type checking allows sting lookalikes to be used. If there were a change, it should probably refactor the function to use ''.join instead of += logic. That would detect the problem and improve the algorithm at the same time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030499&group_id=5470 From noreply at sourceforge.net Thu Sep 30 03:04:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 03:04:44 2004 Subject: [ python-Bugs-1037373 ] len(str(x)) in decimal.py is not Python 2.3 compatible Message-ID: Bugs item #1037373, was opened at 2004-09-29 19:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: len(str(x)) in decimal.py is not Python 2.3 compatible Initial Comment: One of the stated goals of decimal.py is to remain 2.3 compatible. This is not currently the case, as the len(str(x)) trick I used to determine the 'number of digits in an integer' gives the wrong answer for long integers in Python 2.3 (there is an extra 'L' on the end). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-29 21:04 Message: Logged In: YES user_id=31435 Indeed, please give a specific example, and point out exactly what in that example you think should change, and how you think it should change. Else I've got no idea what you're talking about either. >>> import decimal >>> a = decimal.Decimal(3) >>> str(a) '3' >>> len(str(a)) 1 >>> That's under current CVS Python, and I see nothing objectionable in it. I'd bet several pennies it works the same under 2.3.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-29 20:34 Message: Logged In: YES user_id=80475 Check again. str(123L) automatically drops the L repr(123L) keeps it. I had run the decimal tests on Py2.3 without exception. So, please reverify your claim. If valid, show an example where it doesn't work, add that example as a test case, and submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 From noreply at sourceforge.net Thu Sep 30 05:59:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 05:59:48 2004 Subject: [ python-Bugs-1030941 ] Email message croaks the new email pkg parser Message-ID: Bugs item #1030941, was opened at 2004-09-19 20:34 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030941&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Email message croaks the new email pkg parser Initial Comment: The new parser for the email package croaks with an AssertionError on the attached email message. Here's the traceback: Traceback (most recent call last): File "/Users/skip/local/lib/python2.4/site-packages/ spambayes/mboxutils.py", line 129, in get_message msg = email.message_from_string(obj) File "/Users/skip/local/lib/python2.4/email/__init__.py", line 45, in message_from_string return Parser(_class, strict=strict).parsestr(s) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 67, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 56, in parse feedparser.feed(data) File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 145, in feed self._call_parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 149, in _call_parse self._parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 359, in _parsegen assert capturing_preamble Assigning to Barry on the outside chance that he'll have enough round tuits to fix this before the 2.4 release. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-29 23:59 Message: Logged In: YES user_id=12800 msg_42.txt is the boiled down example that evokes the assertion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1030941&group_id=5470 From noreply at sourceforge.net Thu Sep 30 08:09:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 08:09:29 2004 Subject: [ python-Bugs-1037373 ] len(str(x)) in decimal.py is not Python 2.3 compatible Message-ID: Bugs item #1037373, was opened at 2004-09-30 09:36 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: len(str(x)) in decimal.py is not Python 2.3 compatible Initial Comment: One of the stated goals of decimal.py is to remain 2.3 compatible. This is not currently the case, as the len(str(x)) trick I used to determine the 'number of digits in an integer' gives the wrong answer for long integers in Python 2.3 (there is an extra 'L' on the end). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 16:09 Message: Logged In: YES user_id=1038590 Gah, you're right. Sorry - I was doing something else in Py 2.3, and had the L's showing up. And then I overreacted and thought I'd made the same mistake in decimal.py, and created the bug report to make sure I didn't forget to go back and check. However, I was using repr() for what I was doing (whereas decimal.py uses str()). False alarm. Nothing to see here. Move along. . . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-30 11:04 Message: Logged In: YES user_id=31435 Indeed, please give a specific example, and point out exactly what in that example you think should change, and how you think it should change. Else I've got no idea what you're talking about either. >>> import decimal >>> a = decimal.Decimal(3) >>> str(a) '3' >>> len(str(a)) 1 >>> That's under current CVS Python, and I see nothing objectionable in it. I'd bet several pennies it works the same under 2.3.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:34 Message: Logged In: YES user_id=80475 Check again. str(123L) automatically drops the L repr(123L) keeps it. I had run the decimal tests on Py2.3 without exception. So, please reverify your claim. If valid, show an example where it doesn't work, add that example as a test case, and submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1037373&group_id=5470 From noreply at sourceforge.net Thu Sep 30 22:11:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 22:12:04 2004 Subject: [ python-Bugs-1038013 ] textReader: reading after close is a seg fault Message-ID: Bugs item #1038013, was opened at 2004-09-30 23:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1038013&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jyrki Alakuijala (jyrkialakuijala) Assigned to: Nobody/Anonymous (nobody) Summary: textReader: reading after close is a seg fault Initial Comment: Python 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 the code below crashes on fedora core 2: ------------------------------------ import libxml2 file = open("ihanmikavaan.xml", "w") file.write("hajoa!") file.close() reader = libxml2.newTextReaderFilename("ihanmikavaan.xml") reader.Close() # reading after Close is a seg fault, not an exception ret = reader.Read() -------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1038013&group_id=5470