From noreply@sourceforge.net Tue Jan 1 08:46:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Jan 2002 00:46:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Barry Warsaw (bwarsaw) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2002-01-01 00:46 Message: Logged In: YES user_id=412110 Are the Mac folks aware that the spaces impact everyone else, not just them? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-31 06:34 Message: Logged In: YES user_id=6380 Thanks for the patch. I'm assigning this to Barry, who wrote the test. Re spaces in filenames: I think the only filenames with spaces in them occur in the Mac subtree, and the Mac folks insist on having them... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-30 23:18 Message: Logged In: YES user_id=412110 Sorry, I should have thought of providing a patch to begin with. On a separate note, some patches would not be so easy simply because of the filenames containing spaces. You might consider renaming those files. This bit me when I tried to patch the 2.1.1 sources up to 2.2 on a machine stuck behind a slow modem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:43 Message: Logged In: YES user_id=6380 If you want this fixed, please submit a patch. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:12 Message: Logged In: YES user_id=412110 Most software will trust localtime() and gmtime() to interpret the clock. It's only a problem here because you're testing (and thus doubting) the Python bindings to those functions, and rather than check it against some other use of the C functions, you check it against a precomputed string, thus doubting the C functions. C's localtime and gmtime give correct results on my system, because I'm using a time zone designed for a clock that counts all seconds. Don't doubt the C functions; they aren't what you're trying to test. I already explained the point of keeping the clock this way (the TAI scale): it simplifies interval calculations (the difference t1-t0 actually tells you how many seconds passed between those times), and it makes no clock values ambiguous. The NTP scale (counting only non-leap seconds) is a horrible bit of backward compatibility. By depending on it, you punish those with well-configured systems to reward those with badly-configured systems. I mentioned an easy fix, which is to compare the computed string to each of the values seen above, and to pass the test if it matches either of them. This will still fail for people who use even more exotic setups, but I don't know of any such. Is there anything wrong with this? I think the benefit easily outweighs the cost. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Tue Jan 1 20:20:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Jan 2002 12:20:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-497126 ] dl module and flags Message-ID: Bugs item #497126, was opened at 2001-12-27 11:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Martin v. Löwis (loewis) Summary: dl module and flags Initial Comment: With the introduction of sys.setdlopenflags, the dl module got some special usefulness, carrying the flags used in this function. On the other hand, the dl module is not available on every platform where dlopen is. Alpha, for example, is not able to import the dl module because sizeof(int) is not equal to sizeof(long), as the assertion in initdl() ensures. I can think about two obvious solutions: a) Move RTLD_* flags to some standard module (sys?) b) Make some of the functionality in dlmodule.c optional, instead of the whole module. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-01 12:20 Message: Logged In: YES user_id=21627 Thanks again for the patch, applied as setup.py 1.74 ACKS 1.154 NEWS 1.344 dlmodule.c 2.19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:28 Message: Logged In: YES user_id=21627 Looks fine; I'll apply it shortly. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-29 14:23 Message: Logged In: YES user_id=7887 It's ready!! I've attached it to this bug. Please, let me know if any change is needed. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-12-28 12:35 Message: Logged In: YES user_id=7887 Sure... I'll build a patch and let you know. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-28 11:59 Message: Logged In: YES user_id=21627 If you need dlfcn.h constants without having the dl module, you need to run h2py for dlfcn.h. Moving the constants to sys is not acceptable. OTOH, allowing to use dlmodule on all systems seems reasonable. I believe the problem is that dl.call uses a function type that has all arguments "long", and still allows to pass char* and int. So moving the test into dl_call might be appropriate. Would you like to prepare a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497126&group_id=5470 From noreply@sourceforge.net Wed Jan 2 16:05:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 08:05:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-498572 ] smtplib.py AUTH mechanism Message-ID: Bugs item #498572, was opened at 2002-01-02 08:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mauro Cicognini (mcicogni) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.py AUTH mechanism Initial Comment: Currently the AUTH implementation within smtplib.py does not fully comply to RFC 2554. This RFC explicitly states on page 7: auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] *(CRLF [base64]) CRLF Therefore, after the AUTH token there _must_ be an ASCII blank. However, the ESMTP features parsing code uses a RE that will match any alphanumeric string, stopping at the first non-alphanumeric character (smtplib.py, line 394): '(?P[A-Za-z0-9][A-Za-z0-9\-]*)' and will also match, for example, "AUTH=LOGIN", which it shouldn't. This poses a problem when trying to authenticate against an iPlanet Messaging Server MTA, which responds to EHLO with ... (other features) AUTH PLAIN LOGIN STARTTLS AUTH=LOGIN and obviously the second AUTH token "feature list" overwrites the first (we get just ['=LOGIN'], which isn't really useful in any case). I suppose the MTA isn't telling the MUA a second set of AUTH features, but merely letting the MUA know that it may insert the AUTH=<...> parameter on the MAIL FROM command (see the same RFC 2554, section 5, page 4). Anyway, the RFC mandates for a space between the AUTH token and the implemented authentication mechanism list, so this should not be a problem in the first place (smtplib.py could just ignore the improperly-constructed feature line). By the way, the AUTH LOGIN mechanism is iPlanet-Netscape proprietary, so the only well-known method to use in this case would be PLAIN. This "bug" is trivial to fix (just add a space as the last character of the RE) but I don't know about other ESMTP service extensions, which may ask for characters other than space as delimiters. However, I don't know of any existing ESMTP extensions not using the ASCII blank as a token separator, so I think the aforementioned correction could be put in place. Thank you, Mauro Cicognini Siosistemi S.p.A., Italy ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470 From noreply@sourceforge.net Wed Jan 2 17:21:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 09:21:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-498607 ] PyObject_GetIter not documented Message-ID: Bugs item #498607, was opened at 2002-01-02 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498607&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyObject_GetIter not documented Initial Comment: As far as I can tell, the PyObject_GetIter function is not mentioned in the C API documentation. If I understand correctly, it should be listed somewhere on the "6.1 Object Protocol" page. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498607&group_id=5470 From noreply@sourceforge.net Wed Jan 2 17:49:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 09:49:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 09:49 Message: Logged In: YES user_id=85984 This problem has crept up again for the second time now. This time with Python 2.2, and strangely I can't reproduce it with any other Python version. As was the case last time, the hexlify() function is what is causing the segfault. I've attached backtrace_python2.2.txt -- it looks a bit more verbose than previous backtraces. Does this tell us anything new, or is it still a mystery? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 09:06 Message: Logged In: YES user_id=85984 Well, this bug does have to do with Python if only in the configure scripts and such. There is something in Python 2.1.1 that is triggering this that isn't in Python 1.5.2, 2.0 or 2.2. I do agree though that the core of the problem is in FreeBSD, Python 2.1.1 is just bringing it to the surface. There is also some evidence that this problem is fixed in later FreeBSD releases. For example, I can't reproduce the problem on a 4.4-STABLE box (a couple months newer than my 4.4-RELEASE boxes). It would be interesting to see if this problem "dissapears" when I upgrade to 4.5-RELEASE next month. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Wed Jan 2 17:50:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 09:50:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 09:49 Message: Logged In: YES user_id=85984 This problem has crept up again for the second time now. This time with Python 2.2, and strangely I can't reproduce it with any other Python version. As was the case last time, the hexlify() function is what is causing the segfault. I've attached backtrace_python2.2.txt -- it looks a bit more verbose than previous backtraces. Does this tell us anything new, or is it still a mystery? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 09:06 Message: Logged In: YES user_id=85984 Well, this bug does have to do with Python if only in the configure scripts and such. There is something in Python 2.1.1 that is triggering this that isn't in Python 1.5.2, 2.0 or 2.2. I do agree though that the core of the problem is in FreeBSD, Python 2.1.1 is just bringing it to the surface. There is also some evidence that this problem is fixed in later FreeBSD releases. For example, I can't reproduce the problem on a 4.4-STABLE box (a couple months newer than my 4.4-RELEASE boxes). It would be interesting to see if this problem "dissapears" when I upgrade to 4.5-RELEASE next month. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Wed Jan 2 20:06:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 12:06:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 12:06 Message: Logged In: YES user_id=85984 Here is something very strange. I can now reproduce the segfault nearly each time, not just with one particular message. I installed an extension module this morning and after that point things went bad in a hurry. The module is python-cdb (http://pilcrow.madison.wi.us/sw/python-cdb-0.22a.tar.gz) This module was also present in my Python2.1 installation. It appears that removing the cdbmodule.so from my site-packages directory, or not using it in my program clears up the segfault, but as soon as I put it back, Python goes right back to segfaulting. I guess I'll contact the python-cdb maintainer about this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 09:49 Message: Logged In: YES user_id=85984 This problem has crept up again for the second time now. This time with Python 2.2, and strangely I can't reproduce it with any other Python version. As was the case last time, the hexlify() function is what is causing the segfault. I've attached backtrace_python2.2.txt -- it looks a bit more verbose than previous backtraces. Does this tell us anything new, or is it still a mystery? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 09:06 Message: Logged In: YES user_id=85984 Well, this bug does have to do with Python if only in the configure scripts and such. There is something in Python 2.1.1 that is triggering this that isn't in Python 1.5.2, 2.0 or 2.2. I do agree though that the core of the problem is in FreeBSD, Python 2.1.1 is just bringing it to the surface. There is also some evidence that this problem is fixed in later FreeBSD releases. For example, I can't reproduce the problem on a 4.4-STABLE box (a couple months newer than my 4.4-RELEASE boxes). It would be interesting to see if this problem "dissapears" when I upgrade to 4.5-RELEASE next month. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Wed Jan 2 21:43:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 13:43:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-02 13:43 Message: Logged In: NO Right. Bugs in 3rd party modules are very common causes of core dumps, and often there's very little that points to the culprit, because all they do is corrupt memory, placing a landmine for some other innocent code to step on. --Guido (can't log in here on Windows :-) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 12:06 Message: Logged In: YES user_id=85984 Here is something very strange. I can now reproduce the segfault nearly each time, not just with one particular message. I installed an extension module this morning and after that point things went bad in a hurry. The module is python-cdb (http://pilcrow.madison.wi.us/sw/python-cdb-0.22a.tar.gz) This module was also present in my Python2.1 installation. It appears that removing the cdbmodule.so from my site-packages directory, or not using it in my program clears up the segfault, but as soon as I put it back, Python goes right back to segfaulting. I guess I'll contact the python-cdb maintainer about this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 09:49 Message: Logged In: YES user_id=85984 This problem has crept up again for the second time now. This time with Python 2.2, and strangely I can't reproduce it with any other Python version. As was the case last time, the hexlify() function is what is causing the segfault. I've attached backtrace_python2.2.txt -- it looks a bit more verbose than previous backtraces. Does this tell us anything new, or is it still a mystery? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 09:06 Message: Logged In: YES user_id=85984 Well, this bug does have to do with Python if only in the configure scripts and such. There is something in Python 2.1.1 that is triggering this that isn't in Python 1.5.2, 2.0 or 2.2. I do agree though that the core of the problem is in FreeBSD, Python 2.1.1 is just bringing it to the surface. There is also some evidence that this problem is fixed in later FreeBSD releases. For example, I can't reproduce the problem on a 4.4-STABLE box (a couple months newer than my 4.4-RELEASE boxes). It would be interesting to see if this problem "dissapears" when I upgrade to 4.5-RELEASE next month. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Thu Jan 3 03:28:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 19:28:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-498572 ] smtplib.py AUTH mechanism Message-ID: Bugs item #498572, was opened at 2002-01-02 08:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mauro Cicognini (mcicogni) >Assigned to: Barry Warsaw (bwarsaw) Summary: smtplib.py AUTH mechanism Initial Comment: Currently the AUTH implementation within smtplib.py does not fully comply to RFC 2554. This RFC explicitly states on page 7: auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] *(CRLF [base64]) CRLF Therefore, after the AUTH token there _must_ be an ASCII blank. However, the ESMTP features parsing code uses a RE that will match any alphanumeric string, stopping at the first non-alphanumeric character (smtplib.py, line 394): '(?P[A-Za-z0-9][A-Za-z0-9\-]*)' and will also match, for example, "AUTH=LOGIN", which it shouldn't. This poses a problem when trying to authenticate against an iPlanet Messaging Server MTA, which responds to EHLO with ... (other features) AUTH PLAIN LOGIN STARTTLS AUTH=LOGIN and obviously the second AUTH token "feature list" overwrites the first (we get just ['=LOGIN'], which isn't really useful in any case). I suppose the MTA isn't telling the MUA a second set of AUTH features, but merely letting the MUA know that it may insert the AUTH=<...> parameter on the MAIL FROM command (see the same RFC 2554, section 5, page 4). Anyway, the RFC mandates for a space between the AUTH token and the implemented authentication mechanism list, so this should not be a problem in the first place (smtplib.py could just ignore the improperly-constructed feature line). By the way, the AUTH LOGIN mechanism is iPlanet-Netscape proprietary, so the only well-known method to use in this case would be PLAIN. This "bug" is trivial to fix (just add a space as the last character of the RE) but I don't know about other ESMTP service extensions, which may ask for characters other than space as delimiters. However, I don't know of any existing ESMTP extensions not using the ASCII blank as a token separator, so I think the aforementioned correction could be put in place. Thank you, Mauro Cicognini Siosistemi S.p.A., Italy ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 19:28 Message: Logged In: YES user_id=6380 Would you mind submitting a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470 From noreply@sourceforge.net Thu Jan 3 04:21:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 20:21:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-498823 ] Misc/Makefile.pre.in missing Message-ID: Bugs item #498823, was opened at 2002-01-02 20:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 Category: Demos and Tools Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/Makefile.pre.in missing Initial Comment: The Demo/extend directory contains demo files which depend on the presence of Misc/Makefile.pre.in, which is missing from the distribution. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 From noreply@sourceforge.net Thu Jan 3 04:53:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 20:53:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-498828 ] SyntaxError reports wrong module name Message-ID: Bugs item #498828, was opened at 2002-01-02 20:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498828&group_id=5470 Category: None Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Atsuo Ishimoto (atsuoi) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError reports wrong module name Initial Comment: With Python 2.2, importing this module == xxx.py === def abcdefg(l): l.append("kfda" doesn't show module name 'xxx' in traceback info. >>> import xxx Traceback (most recent call last): File "", line 1, in ? File "", line 3 l.append("kfda" ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498828&group_id=5470 From noreply@sourceforge.net Thu Jan 3 04:59:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 20:59:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-498823 ] Misc/Makefile.pre.in missing Message-ID: Bugs item #498823, was opened at 2002-01-02 20:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 Category: Demos and Tools Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Guido van Rossum (gvanrossum) Summary: Misc/Makefile.pre.in missing Initial Comment: The Demo/extend directory contains demo files which depend on the presence of Misc/Makefile.pre.in, which is missing from the distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 20:59 Message: Logged In: YES user_id=6380 This was reported before, and has been fixed in CVS already. The Demo/extend directory is obsolete. Use the distutils package; docs are part of the standard 2.2 documentation bundle. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 From noreply@sourceforge.net Thu Jan 3 05:33:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 21:33:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-498823 ] Misc/Makefile.pre.in missing Message-ID: Bugs item #498823, was opened at 2002-01-02 20:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 Category: Demos and Tools Group: Python 2.2 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Guido van Rossum (gvanrossum) Summary: Misc/Makefile.pre.in missing Initial Comment: The Demo/extend directory contains demo files which depend on the presence of Misc/Makefile.pre.in, which is missing from the distribution. ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2002-01-02 21:33 Message: Logged In: YES user_id=52572 In case it's not already known: there are also lots of docs in the extending/embedding section which depend on that file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 20:59 Message: Logged In: YES user_id=6380 This was reported before, and has been fixed in CVS already. The Demo/extend directory is obsolete. Use the distutils package; docs are part of the standard 2.2 documentation bundle. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 From noreply@sourceforge.net Thu Jan 3 05:49:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 21:49:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-498823 ] Misc/Makefile.pre.in missing Message-ID: Bugs item #498823, was opened at 2002-01-02 20:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 Category: Demos and Tools Group: Python 2.2 >Status: Open Resolution: Duplicate Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Misc/Makefile.pre.in missing Initial Comment: The Demo/extend directory contains demo files which depend on the presence of Misc/Makefile.pre.in, which is missing from the distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 21:49 Message: Logged In: YES user_id=6380 OK, reopened and assigned to Fred. Fred, feel free to close this if you already have a reminder for that. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-01-02 21:33 Message: Logged In: YES user_id=52572 In case it's not already known: there are also lots of docs in the extending/embedding section which depend on that file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 20:59 Message: Logged In: YES user_id=6380 This was reported before, and has been fixed in CVS already. The Demo/extend directory is obsolete. Use the distutils package; docs are part of the standard 2.2 documentation bundle. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 From noreply@sourceforge.net Thu Jan 3 06:58:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Jan 2002 22:58:43 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-498855 ] add POST support to webbrowser module Message-ID: Feature Requests item #498855, was opened at 2002-01-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: add POST support to webbrowser module Initial Comment: This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 From noreply@sourceforge.net Thu Jan 3 11:29:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 03:29:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-498915 ] PyMapping_DelItemString doesn't exists Message-ID: Bugs item #498915, was opened at 2002-01-03 03:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: PyMapping_DelItemString doesn't exists Initial Comment: This bug seems related to https://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=476852 Python 2.2 here. "PyMapping_DelItemString" is really a macro (defined in "abstract.h") which delegates to "PyObject_DelItemString". The problem is that "PyObjectDelItemString" *DOESN'T* exists. I have changed my code to call PyDict_* routines instead the previous PyMapping_* to overcome this issue temporally. This is almost a "showstop" bug :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 From noreply@sourceforge.net Thu Jan 3 11:30:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 03:30:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-498915 ] PyMapping_DelItemString doesn't exists Message-ID: Bugs item #498915, was opened at 2002-01-03 03:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Jesús Cea Avión (jcea) >Assigned to: Martin v. Löwis (loewis) Summary: PyMapping_DelItemString doesn't exists Initial Comment: This bug seems related to https://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=476852 Python 2.2 here. "PyMapping_DelItemString" is really a macro (defined in "abstract.h") which delegates to "PyObject_DelItemString". The problem is that "PyObjectDelItemString" *DOESN'T* exists. I have changed my code to call PyDict_* routines instead the previous PyMapping_* to overcome this issue temporally. This is almost a "showstop" bug :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 From noreply@sourceforge.net Thu Jan 3 13:44:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 05:44:15 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-498855 ] add POST support to webbrowser module Message-ID: Feature Requests item #498855, was opened at 2002-01-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: add POST support to webbrowser module Initial Comment: This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:44 Message: Logged In: YES user_id=6380 Why would you need this? I find it hard to imagine a situation where I'd need this. Almost any forms that I would want to reach through webbrowser support GET anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 From noreply@sourceforge.net Thu Jan 3 13:50:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 05:50:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-498915 ] PyMapping_DelItemString doesn't exists Message-ID: Bugs item #498915, was opened at 2002-01-03 03:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Jesús Cea Avión (jcea) >Assigned to: Jeremy Hylton (jhylton) Summary: PyMapping_DelItemString doesn't exists Initial Comment: This bug seems related to https://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=476852 Python 2.2 here. "PyMapping_DelItemString" is really a macro (defined in "abstract.h") which delegates to "PyObject_DelItemString". The problem is that "PyObjectDelItemString" *DOESN'T* exists. I have changed my code to call PyDict_* routines instead the previous PyMapping_* to overcome this issue temporally. This is almost a "showstop" bug :-) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:50 Message: Logged In: YES user_id=6380 Oops, you're right! Our apologies. A fix wouldn't be hard, but since we're all busy here with high priority stuff, it may take a while. If you can submit a patch, that would make things easier. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 From noreply@sourceforge.net Thu Jan 3 18:48:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 10:48:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-498915 ] PyMapping_DelItemString doesn't exists Message-ID: Bugs item #498915, was opened at 2002-01-03 03:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Jeremy Hylton (jhylton) Summary: PyMapping_DelItemString doesn't exists Initial Comment: This bug seems related to https://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=476852 Python 2.2 here. "PyMapping_DelItemString" is really a macro (defined in "abstract.h") which delegates to "PyObject_DelItemString". The problem is that "PyObjectDelItemString" *DOESN'T* exists. I have changed my code to call PyDict_* routines instead the previous PyMapping_* to overcome this issue temporally. This is almost a "showstop" bug :-) ---------------------------------------------------------------------- >Comment By: Jesús Cea Avión (jcea) Date: 2002-01-03 10:48 Message: Logged In: YES user_id=97460 This patch should be studied by somebody familiar enough with Python inner working, buit it seems to run fine in my environment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:50 Message: Logged In: YES user_id=6380 Oops, you're right! Our apologies. A fix wouldn't be hard, but since we're all busy here with high priority stuff, it may take a while. If you can submit a patch, that would make things easier. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 From noreply@sourceforge.net Thu Jan 3 18:51:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 10:51:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-498915 ] PyMapping_DelItemString doesn't exists Message-ID: Bugs item #498915, was opened at 2002-01-03 03:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Jesús Cea Avión (jcea) Assigned to: Jeremy Hylton (jhylton) Summary: PyMapping_DelItemString doesn't exists Initial Comment: This bug seems related to https://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=476852 Python 2.2 here. "PyMapping_DelItemString" is really a macro (defined in "abstract.h") which delegates to "PyObject_DelItemString". The problem is that "PyObjectDelItemString" *DOESN'T* exists. I have changed my code to call PyDict_* routines instead the previous PyMapping_* to overcome this issue temporally. This is almost a "showstop" bug :-) ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-01-03 10:48 Message: Logged In: YES user_id=97460 This patch should be studied by somebody familiar enough with Python inner working, buit it seems to run fine in my environment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:50 Message: Logged In: YES user_id=6380 Oops, you're right! Our apologies. A fix wouldn't be hard, but since we're all busy here with high priority stuff, it may take a while. If you can submit a patch, that would make things easier. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 From noreply@sourceforge.net Thu Jan 3 18:58:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 10:58:27 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-498855 ] add POST support to webbrowser module Message-ID: Feature Requests item #498855, was opened at 2002-01-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: add POST support to webbrowser module Initial Comment: This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed". ---------------------------------------------------------------------- >Comment By: Kevin Altis (kasplat) Date: 2002-01-03 10:58 Message: Logged In: YES user_id=228025 If POST is not supported, there is a limit to the size of data that you can send; the limit will be different depending on each browser, but will always be less than 4K URL length limit. Many sites don't accept GET instead of POST for form data. Unfortunately, it is often difficult to tell whether a site accepts GET without changing the form manually and attempting a GET. Sometimes the reason that GET isn't accepted is do to lazy programming, but since a user can't do anything about that they still end up needing POST. Other times it is specifically because a site doesn't want the POST data to be cached. Any GET request will end up getting cached in proxies, show up in server logs, and also cached on the local client. All of these are bad from a security standpoint. POST data is never cached. This is not a critical addition to the webbrowser module, it simply makes it more complete. It is still possible to do POST another way and Windows programs can always drive Internet Explorer via COM or DDE, but I think POST in webbrowser would make a nice addition for the future. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:44 Message: Logged In: YES user_id=6380 Why would you need this? I find it hard to imagine a situation where I'd need this. Almost any forms that I would want to reach through webbrowser support GET anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 From noreply@sourceforge.net Thu Jan 3 19:08:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 11:08:12 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-498855 ] add POST support to webbrowser module Message-ID: Feature Requests item #498855, was opened at 2002-01-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: add POST support to webbrowser module Initial Comment: This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 11:08 Message: Logged In: YES user_id=6380 I still don't understand why you would need to do this. urllib supports POST. But the webbrowser module directs the user's browser to a website. Can you give an *example* of when you need this? Otherwise I'll just reject it -- I don't think this is possible anyway for most browsers except IE. ---------------------------------------------------------------------- Comment By: Kevin Altis (kasplat) Date: 2002-01-03 10:58 Message: Logged In: YES user_id=228025 If POST is not supported, there is a limit to the size of data that you can send; the limit will be different depending on each browser, but will always be less than 4K URL length limit. Many sites don't accept GET instead of POST for form data. Unfortunately, it is often difficult to tell whether a site accepts GET without changing the form manually and attempting a GET. Sometimes the reason that GET isn't accepted is do to lazy programming, but since a user can't do anything about that they still end up needing POST. Other times it is specifically because a site doesn't want the POST data to be cached. Any GET request will end up getting cached in proxies, show up in server logs, and also cached on the local client. All of these are bad from a security standpoint. POST data is never cached. This is not a critical addition to the webbrowser module, it simply makes it more complete. It is still possible to do POST another way and Windows programs can always drive Internet Explorer via COM or DDE, but I think POST in webbrowser would make a nice addition for the future. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:44 Message: Logged In: YES user_id=6380 Why would you need this? I find it hard to imagine a situation where I'd need this. Almost any forms that I would want to reach through webbrowser support GET anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 From noreply@sourceforge.net Thu Jan 3 23:09:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 15:09:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-499169 ] imaplib.Time2Internaldate is broken Message-ID: Bugs item #499169, was opened at 2002-01-03 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib.Time2Internaldate is broken Initial Comment: The type tests in this function have stopped working because the return type of time.gmtime() and friends is now time.struct_time and not tuple. Secondly, the format string used for the timezone is '%+02d%02d'. I believe it should be '%+03d02d' since the first field width includes the sign character. A patch that works for me (note that it lets strftime do its own type-checking): --- imaplib.py~ Tue Oct 30 00:56:40 2001 +++ imaplib.py Thu Jan 3 18:42:22 2002 @@ -1070,13 +1070,12 @@ """ dttype = type(date_time) - if dttype is type(1) or dttype is type(1.1): + if dttype is str: + return date_time + if dttype is int or dttype is float: tt = time.localtime(date_time) - elif dttype is type(()): + else: tt = date_time - elif dttype is type(""): - return date_time # Assume in correct format - else: raise ValueError dt = time.strftime("%d-%b-%Y %H:%M:%S", tt) if dt[0] == '0': @@ -1085,7 +1084,7 @@ zone = -time.altzone else: zone = -time.timezone - return '"' + dt + " %+02d%02d" % divmod(zone/60, 60) + '"' + return '"' + dt + " %+03d%02d" % divmod(zone/60, 60) + '"' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 From noreply@sourceforge.net Fri Jan 4 05:05:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 21:05:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-210667 ] select module: Bug in select.select() (PR#365) Message-ID: Bugs item #210667, was opened at 2000-07-31 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210667&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: select module: Bug in select.select() (PR#365) Initial Comment: Jitterbug-Id: 365 Submitted-By: r32813@email.sps.mot.com Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT) Version: 1.5.2 OS: AIX 4.3.1 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when this command was run:- select.select(waitList, [], [], timeWait) This command worked fine in Python 1.5.1 build and also fine on Python 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on 2 AIX machines that we have. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-03 21:05 Message: Logged In: NO this appears to be a stack problem, which would explain the mysterious backtrace. on AIX (4.3.3), the FD_SETSIZE is 32k, so at 12 bytes per array and 3 arrays of 32k, that is a little over 1Mb on the stack. there is already some code to handle this for Windows, so adding an additional check for AIX should fix the problem. of course it would be nicer for a solution that didn't need to allocate and free all that memory every time select is called. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2000-09-28 15:21 Message: It seems impossible to reproduce this without actually having an AIX box, and IBM has no equivalent of Compaq's test drive, unfortunately. At first blush, it's difficult to come up with a hypothesis; why would the *tout = Py_None line cause a segfault? Perhaps a refcounting bug decreased the RC of _Py_None_struct to 0 and caused it to be deallocated, but that shouldn't crash on that line of code. I'm going to mark this "Works for Me", pending further reports from the original submitter, or from anyone else. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 21:55 Message: Just putting the fellow's test_thread_select.py here as plain text (it's given only as base64 below): # Testing select module from test_support import verbose import select, thread, Queue import os # test some known error conditions try: rfd, wfd, xfd = select.select(1, 2, 3) except TypeError: pass else: print 'expected TypeError exception not raised' class Nope: pass class Almost: def fileno(self): return 'fileno' try: rfd, wfd, xfd = select.select([Nope()], [], []) except TypeError: pass else: print 'expected TypeError exception not raised' try: rfd, wfd, xfd = select.select([Almost()], [], []) except TypeError: pass else: print 'expected TypeError exception not raised' def test(q): import sys if sys.platform[:3] in ('win', 'mac', 'os2'): if verbose: print "Can't test select easily on", sys.platform return cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done' p = os.popen(cmd, 'r') for tout in (0, 1, 2, 4, 8, 16) + (None,)*10: if verbose: print 'timeout =', tout rfd, wfd, xfd = select.select([p], [], [], tout) ## print rfd, wfd, xfd if (rfd, wfd, xfd) == ([], [], []): continue if (rfd, wfd, xfd) == ([p], [], []): line = p.readline() if verbose: print `line` if not line: if verbose: print 'EOF' break continue print 'Heh?' p.close() q.put(1) q = Queue.Queue(1) thread.start_new_thread(test,(q,)) #wait for thread to complete test function done = q.get() print 'thread completed test, exiting' ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:01 Message: From: Guido van Rossum Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Fri, 23 Jun 2000 11:01:40 -0500 > Below is the dbx information from the coredump. This only occurs when the > select.select() function is used within a thread. This same error occurs on > both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not > occur on AIX 4.1.4. > > $ dbx -I ./Modules ./python core > Type 'help' for help. > reading symbolic information ... > [using memory image in core] > > Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" > ($t2) > 235 PyObject *tout = Py_None; Thanks. Could you do this again and also type the "bt" (backtrace) command? That would perhaps be more helpful. We can't reproduce this here since we don't have access to AIX! (Even if we ha,d it would be low priority :-( ). --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:01 Message: From: "Wahmeng Wong" Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Thu, 22 Jun 2000 19:02:11 -0700 This is a multi-part message in MIME format. --------------F9E74BCE6963FE221E423528 Content-Type: multipart/alternative; boundary="------------FF8E270086909CA1DBDDA697" --------------FF8E270086909CA1DBDDA697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido, Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4. $ dbx -I ./Modules ./python core Type 'help' for help. reading symbolic information ... [using memory image in core] Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2) 235 PyObject *tout = Py_None; We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem. Thanks for all your help. Regards, Wah Meng Guido van Rossum wrote: > > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > > this command was run:- > > > > select.select(waitList, [], [], timeWait) > > > > This command worked fine in Python 1.5.1 build and also fine on Python > > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > > 2 AIX machines that we have. > > Could you give us some more information? You're indicating that it's > platform specific; we don't have an AIX box. I'm guessing it's not > obvious that our code is wrong, but it may violate some guidelines > given by AIX manuals. If we ever want to fix this, we'll need to > interact with you. the first thing we need is a decent stack trace; > we'll take it from there. > > If you could investigate this on your own and come up with a fix, that > would probably the best solution... > > --Guido van Rossum (home page: http://www.python.org/~guido/) --------------FF8E270086909CA1DBDDA697 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido,

Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4.

$ dbx -I ./Modules ./python core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2)
  235           PyObject *tout = Py_None;

We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem.

Thanks for all your help.

Regards,
Wah Meng

Guido van Rossum wrote:

>  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when
>  this command was run:-
>
>        select.select(waitList, [], [], timeWait)
>
>  This command worked fine in Python 1.5.1 build and also fine on Python
>  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
>  2 AIX machines that we have.

Could you give us some more information?  You're indicating that it's
platform specific; we don't have an AIX box.  I'm guessing it's not
obvious that our code is wrong, but it may violate some guidelines
given by AIX manuals.  If we ever want to fix this, we'll need to
interact with you.  the first thing we need is a decent stack trace;
we'll take it from there.

If you could investigate this on your own and come up with a fix, that
would probably the best solution...

--Guido van Rossum (home page: http://www.python.org/~guido/)

--------------FF8E270086909CA1DBDDA697-- --------------F9E74BCE6963FE221E423528 Content-Type: application/x-unknown-content-type-Python.File; name="test_thread_select.py" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="test_thread_select.py" IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0 IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0 Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1 dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu ZycNCg0K --------------F9E74BCE6963FE221E423528-- ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:01 Message: From: Guido van Rossum Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Wed, 21 Jun 2000 17:08:33 -0500 > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > this command was run:- > > select.select(waitList, [], [], timeWait) > > This command worked fine in Python 1.5.1 build and also fine on Python > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > 2 AIX machines that we have. Could you give us some more information? You're indicating that it's platform specific; we don't have an AIX box. I'm guessing it's not obvious that our code is wrong, but it may violate some guidelines given by AIX manuals. If we ever want to fix this, we'll need to interact with you. the first thing we need is a decent stack trace; we'll take it from there. If you could investigate this on your own and come up with a fix, that would probably the best solution... --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210667&group_id=5470 From noreply@sourceforge.net Fri Jan 4 05:15:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Jan 2002 21:15:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-210667 ] select module: Bug in select.select() (PR#365) Message-ID: Bugs item #210667, was opened at 2000-07-31 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210667&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: select module: Bug in select.select() (PR#365) Initial Comment: Jitterbug-Id: 365 Submitted-By: r32813@email.sps.mot.com Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT) Version: 1.5.2 OS: AIX 4.3.1 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when this command was run:- select.select(waitList, [], [], timeWait) This command worked fine in Python 1.5.1 build and also fine on Python 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on 2 AIX machines that we have. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 21:15 Message: Logged In: YES user_id=6380 Try Python 2.2. This allocates the sets on the heap if FS_SETSIZE is > 1024 regardless of platform. If you want a less memory-intensive solution, try poll(). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-03 21:05 Message: Logged In: NO this appears to be a stack problem, which would explain the mysterious backtrace. on AIX (4.3.3), the FD_SETSIZE is 32k, so at 12 bytes per array and 3 arrays of 32k, that is a little over 1Mb on the stack. there is already some code to handle this for Windows, so adding an additional check for AIX should fix the problem. of course it would be nicer for a solution that didn't need to allocate and free all that memory every time select is called. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2000-09-28 15:21 Message: It seems impossible to reproduce this without actually having an AIX box, and IBM has no equivalent of Compaq's test drive, unfortunately. At first blush, it's difficult to come up with a hypothesis; why would the *tout = Py_None line cause a segfault? Perhaps a refcounting bug decreased the RC of _Py_None_struct to 0 and caused it to be deallocated, but that shouldn't crash on that line of code. I'm going to mark this "Works for Me", pending further reports from the original submitter, or from anyone else. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 21:55 Message: Just putting the fellow's test_thread_select.py here as plain text (it's given only as base64 below): # Testing select module from test_support import verbose import select, thread, Queue import os # test some known error conditions try: rfd, wfd, xfd = select.select(1, 2, 3) except TypeError: pass else: print 'expected TypeError exception not raised' class Nope: pass class Almost: def fileno(self): return 'fileno' try: rfd, wfd, xfd = select.select([Nope()], [], []) except TypeError: pass else: print 'expected TypeError exception not raised' try: rfd, wfd, xfd = select.select([Almost()], [], []) except TypeError: pass else: print 'expected TypeError exception not raised' def test(q): import sys if sys.platform[:3] in ('win', 'mac', 'os2'): if verbose: print "Can't test select easily on", sys.platform return cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done' p = os.popen(cmd, 'r') for tout in (0, 1, 2, 4, 8, 16) + (None,)*10: if verbose: print 'timeout =', tout rfd, wfd, xfd = select.select([p], [], [], tout) ## print rfd, wfd, xfd if (rfd, wfd, xfd) == ([], [], []): continue if (rfd, wfd, xfd) == ([p], [], []): line = p.readline() if verbose: print `line` if not line: if verbose: print 'EOF' break continue print 'Heh?' p.close() q.put(1) q = Queue.Queue(1) thread.start_new_thread(test,(q,)) #wait for thread to complete test function done = q.get() print 'thread completed test, exiting' ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:01 Message: From: Guido van Rossum Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Fri, 23 Jun 2000 11:01:40 -0500 > Below is the dbx information from the coredump. This only occurs when the > select.select() function is used within a thread. This same error occurs on > both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not > occur on AIX 4.1.4. > > $ dbx -I ./Modules ./python core > Type 'help' for help. > reading symbolic information ... > [using memory image in core] > > Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" > ($t2) > 235 PyObject *tout = Py_None; Thanks. Could you do this again and also type the "bt" (backtrace) command? That would perhaps be more helpful. We can't reproduce this here since we don't have access to AIX! (Even if we ha,d it would be low priority :-( ). --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:01 Message: From: "Wahmeng Wong" Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Thu, 22 Jun 2000 19:02:11 -0700 This is a multi-part message in MIME format. --------------F9E74BCE6963FE221E423528 Content-Type: multipart/alternative; boundary="------------FF8E270086909CA1DBDDA697" --------------FF8E270086909CA1DBDDA697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido, Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4. $ dbx -I ./Modules ./python core Type 'help' for help. reading symbolic information ... [using memory image in core] Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2) 235 PyObject *tout = Py_None; We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem. Thanks for all your help. Regards, Wah Meng Guido van Rossum wrote: > > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > > this command was run:- > > > > select.select(waitList, [], [], timeWait) > > > > This command worked fine in Python 1.5.1 build and also fine on Python > > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > > 2 AIX machines that we have. > > Could you give us some more information? You're indicating that it's > platform specific; we don't have an AIX box. I'm guessing it's not > obvious that our code is wrong, but it may violate some guidelines > given by AIX manuals. If we ever want to fix this, we'll need to > interact with you. the first thing we need is a decent stack trace; > we'll take it from there. > > If you could investigate this on your own and come up with a fix, that > would probably the best solution... > > --Guido van Rossum (home page: http://www.python.org/~guido/) --------------FF8E270086909CA1DBDDA697 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido,

Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4.

$ dbx -I ./Modules ./python core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2)
  235           PyObject *tout = Py_None;

We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem.

Thanks for all your help.

Regards,
Wah Meng

Guido van Rossum wrote:

>  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when
>  this command was run:-
>
>        select.select(waitList, [], [], timeWait)
>
>  This command worked fine in Python 1.5.1 build and also fine on Python
>  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
>  2 AIX machines that we have.

Could you give us some more information?  You're indicating that it's
platform specific; we don't have an AIX box.  I'm guessing it's not
obvious that our code is wrong, but it may violate some guidelines
given by AIX manuals.  If we ever want to fix this, we'll need to
interact with you.  the first thing we need is a decent stack trace;
we'll take it from there.

If you could investigate this on your own and come up with a fix, that
would probably the best solution...

--Guido van Rossum (home page: http://www.python.org/~guido/)

--------------FF8E270086909CA1DBDDA697-- --------------F9E74BCE6963FE221E423528 Content-Type: application/x-unknown-content-type-Python.File; name="test_thread_select.py" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="test_thread_select.py" IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0 IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0 Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1 dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu ZycNCg0K --------------F9E74BCE6963FE221E423528-- ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:01 Message: From: Guido van Rossum Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Wed, 21 Jun 2000 17:08:33 -0500 > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > this command was run:- > > select.select(waitList, [], [], timeWait) > > This command worked fine in Python 1.5.1 build and also fine on Python > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > 2 AIX machines that we have. Could you give us some more information? You're indicating that it's platform specific; we don't have an AIX box. I'm guessing it's not obvious that our code is wrong, but it may violate some guidelines given by AIX manuals. If we ever want to fix this, we'll need to interact with you. the first thing we need is a decent stack trace; we'll take it from there. If you could investigate this on your own and come up with a fix, that would probably the best solution... --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210667&group_id=5470 From noreply@sourceforge.net Fri Jan 4 16:53:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 08:53:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING Message-ID: Bugs item #411612, was opened at 2001-03-27 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Viktor Fougstedt (viktordt) Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.py sometimes ignores QUERY_STRING Initial Comment: [Using Python 2.0/Sparc Solaris 8, should be independent of operating system] cgi.py sometimes ignores the QUERY_STRING when REQUEST_METHOD is POST. The CGI specifications says nothing about how programs should respond to this particular combination. It does however state that QUERY_STRING should always be set by the server, regardless of the request method. Since QUERY_STRING is set, it seems reasonable that the cgi module should parse it as well and not just ignore it. If cgi.py intentionally ignores QUERY_STRING under these circumstances, I think it should be documented. :-) What this means is that if i have a HTML form a'la
and some_cgi is a python script using cgi.py, I should get both foo and bar set. Currently, the QUERY_STRING (i.e. "foo=foo") is ignored, and only bar gets set by cgi.py. I consider this a "bug" insofar as it is an unexpected and somewhat inconsistent behaviour. If I e.g. use the url "/cgi-bin/myprog/session_id=10023" everywhere in my program, I must suddenly alter it if the URL is used in a FORM action attribute, and instead insert a hidden variable called session_id into the form to get cgi.py to parse it. The parse() function in cgi.py correctly checks and appends QUERY_STRING if it is set. But the FieldStorage read_urlencoded() method does not, and that is the function that is actually used, not cgi.parse(). The fix should be to add two lines (marked with '>' below) after the initial assignment to qs in the read_urlencoded() method of the FieldStorage class so that it begins: def read_urlencoded(self): """Internal: read data in query string format.""" qs = self.fp.read(self.length) if os.environ.has_key('QUERY_STRING'): if qs: qs = qs + '&' qs = qs + environ['QUERY_STRING'] (the three last lines are new, and identical to the three lines in the cgi.parse() function which accomplishes the same task). ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2002-01-04 08:53 Message: Logged In: YES user_id=88157 [Left this until the 2.2 dust had cleared. Happy New Year]. I will work on something for inclusion in the next release. My approach will be to have the new functionality depend on the provision of additional keyword arguments whose default values give the existing behavior: I'm not convinced that CGI does substantially the wrong thing here, and the user needs to determine whether query string values should be merged in or used to override POST input values. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-04 11:16 Message: Logged In: YES user_id=6380 Rejected for lack of time. I don't have the time to figure out what the right behavior should be, and the patch appears to be broken. Steve Holden, perhaps you might want to submit a patch (for Python 2.3) that does what you think is correct? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 04:00 Message: Logged In: YES user_id=88157 This appears to be a somewhat grey area: certainly the CGI specifications say that the QUERY_STRING must be made available, but does it make sense to treat QUERY_STRING data as of equal importance when standard input is present in a POST method request? In particular, if QUERY_STRING contains "spam=eggs" and the standard input contains "spam=chips" then should FieldStorage().getitem("spam") return ["eggs", "chips"]? Appealing to the behaviour of other servers is possibly not the best guide for the cgi library's action, but it might be instructive to see how other systems have approached this problem before changes are made. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:30 Message: Logged In: YES user_id=6380 The idea is right, but since nobody volunteered a working patch, this won't make it into 2.1. Sorry. Try again after 2.1! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-27 04:23 Message: Logged In: NO Quick check: That "fix" does not work. It duplicates the QUERY_STRING if you use the GET method. Additional checks are necessary to ensure correct operation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 From noreply@sourceforge.net Fri Jan 4 18:09:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 10:09:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-499505 ] Tiny bug in lib doc 16.1.2.2 Message-ID: Bugs item #499505, was opened at 2002-01-04 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499505&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tiny bug in lib doc 16.1.2.2 Initial Comment: The Python library reference, release 2.2, section 16.1.2.2 contains a code example that includes the following: def __init__(self, master=None): 22 Frame.__init__(self, master) 23 self.pack() 24 self.createWidgets() 25 The third of these lines (with number 24 in the right margin) should have the same indentation as its neighbors. It won't compile as it stands. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499505&group_id=5470 From noreply@sourceforge.net Fri Jan 4 18:54:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 10:54:25 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-499529 ] email.Utils.msgid() Message-ID: Feature Requests item #499529, was opened at 2002-01-04 10:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=499529&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: email.Utils.msgid() Initial Comment: It seems the Python library does not include a general method for creating an rfc2822 compliant Message-ID string. This would be useful for e-mail applications that need to generate their own Message-IDs. If you are interested in adding this method, I can include a patch against Utils.py from the email module. I've already implemented this functionality in Python for one of my applications. It produces Message-ID strings that look like: <20020104184922.4077.30184.tmda@ns.mastaler.com> date + random integer + process id + a string @ FQDN Let me know if you are interested, and also preference on the name of the method (you may prefer something other than msgid()). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=499529&group_id=5470 From noreply@sourceforge.net Sat Jan 5 00:39:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 16:39:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-499656 ] OPT envar not propagated to Makefile Message-ID: Bugs item #499656, was opened at 2002-01-04 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: OPT envar not propagated to Makefile Initial Comment: In Python 2.2 the following builds Python with -g and no -O on Linux % OPT=-g ./configure ; make But in Python 2.1.2, OPT does not propagate to the Makefile, so you'd still have to do % OPT=-g ./configure ; make OPT=-g This breaks the suggested recipe in posix-large-file manpage for building LFS on Python 2.1.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 From noreply@sourceforge.net Sat Jan 5 00:41:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 16:41:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-499656 ] OPT envar not propagated to Makefile Message-ID: Bugs item #499656, was opened at 2002-01-04 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: OPT envar not propagated to Makefile Initial Comment: In Python 2.2 the following builds Python with -g and no -O on Linux % OPT=-g ./configure ; make But in Python 2.1.2, OPT does not propagate to the Makefile, so you'd still have to do % OPT=-g ./configure ; make OPT=-g This breaks the suggested recipe in posix-large-file manpage for building LFS on Python 2.1.2. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-04 16:41 Message: Logged In: YES user_id=3066 Should CFLAGS be handled in the same way? I'm really not sure. I'll see what the autoconf book says. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 From noreply@sourceforge.net Sat Jan 5 03:46:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 19:46:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-499708 ] Int(long) causes Integer Overflow Message-ID: Bugs item #499708, was opened at 2002-01-04 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499708&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Int(long) causes Integer Overflow Initial Comment: In the spirit of unifying longs and ints, should int() be the sole way of truncating floats or should the programmer be responsible for categorizing and handling ints and longs separately? >>> int( 12341234123.4 ) Traceback (most recent call last): File "", line 1, in ? OverflowError: float too large to convert >>> def myint(f): ... try: ... return int(f) ... except OverflowError: ... return long(f) ... >>> myint( 12341234123.4 ) 12341234123L >>> myint(123.4) 123 I have one misgiving about fixing this one. assert type(int(x)) == int, 'should always succeed' would fail for when x=12341234123.4 The only way around this is to make longs return a IntType. Who knows what this would break. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499708&group_id=5470 From noreply@sourceforge.net Sat Jan 5 03:58:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 19:58:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-499505 ] Tiny bug in lib doc 16.1.2.2 Message-ID: Bugs item #499505, was opened at 2002-01-04 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499505&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tiny bug in lib doc 16.1.2.2 Initial Comment: The Python library reference, release 2.2, section 16.1.2.2 contains a code example that includes the following: def __init__(self, master=None): 22 Frame.__init__(self, master) 23 self.pack() 24 self.createWidgets() 25 The third of these lines (with number 24 in the right margin) should have the same indentation as its neighbors. It won't compile as it stands. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-04 19:58 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/tkinter.tex revision 1.11 and 1.10.6.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499505&group_id=5470 From noreply@sourceforge.net Sat Jan 5 04:18:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 20:18:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-499656 ] OPT envar not propagated to Makefile Message-ID: Bugs item #499656, was opened at 2002-01-04 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: OPT envar not propagated to Makefile Initial Comment: In Python 2.2 the following builds Python with -g and no -O on Linux % OPT=-g ./configure ; make But in Python 2.1.2, OPT does not propagate to the Makefile, so you'd still have to do % OPT=-g ./configure ; make OPT=-g This breaks the suggested recipe in posix-large-file manpage for building LFS on Python 2.1.2. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-04 20:18 Message: Logged In: YES user_id=3066 Here's what I see: OPT is used to accumulate lots of options all through configure.in, but there are a few places (notably the earlier uses) which set OPT without including the old value in the definition. It's easy enough to change these so that the old value is always included. What that does not accomplish is to allow the user to set OPT to avoid the configure script changing or augmenting it; I don't think that's the right thing. Should we make the effort to only set it if it wasn't set in the passed-in environment? Should we use re-arrange the addition of options to the compiler command line to use CPPFLAGS and CFLAGS instead, where the flags are not specific to optimization? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-04 16:41 Message: Logged In: YES user_id=3066 Should CFLAGS be handled in the same way? I'm really not sure. I'll see what the autoconf book says. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 From noreply@sourceforge.net Sat Jan 5 06:34:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 22:34:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-499656 ] OPT envar not propagated to Makefile Message-ID: Bugs item #499656, was opened at 2002-01-04 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 6 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: OPT envar not propagated to Makefile Initial Comment: In Python 2.2 the following builds Python with -g and no -O on Linux % OPT=-g ./configure ; make But in Python 2.1.2, OPT does not propagate to the Makefile, so you'd still have to do % OPT=-g ./configure ; make OPT=-g This breaks the suggested recipe in posix-large-file manpage for building LFS on Python 2.1.2. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-04 22:34 Message: Logged In: YES user_id=21627 In 2.1.2 (configure.in 1.215.2.7), it is only BeOS that sets OPT without checking a prior value (line 112); for the problem in question (LFS), I think this is safe to ignore. It is then dgux that augments it unconditionally (with -pic, line 268); this seems reasonable. Then, in line 308, it *does* check for a prior value, and only sets it if it was empty before. Since this is the place where it also gets its eventual value on most systems, I think this needs no changes. Later assignment to OPT use it as a vehicle to get additional arguments into the compiler command line (e.g. line 340, 528). These must not consider a prior value, since having those options is essential for the configuration, and the user is not supposed to ignore them. If the user really wants to, she should edit the resulting Makefile, or pass the override settings on the make command line. The -Olimit flags are probably a special case, anyway: I think they should be removed entirely, since I suppose the systems where they are useful have been turned off years ago. To summarize, I cannot reproduce the problem: % OPT=-g ./configure creating cache ./config.cache ... % make gcc -c -g -I. -I./Include -DHAVE_CONFIG_H -o Modules/python.o Modules/python.c works fine for me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-04 20:18 Message: Logged In: YES user_id=3066 Here's what I see: OPT is used to accumulate lots of options all through configure.in, but there are a few places (notably the earlier uses) which set OPT without including the old value in the definition. It's easy enough to change these so that the old value is always included. What that does not accomplish is to allow the user to set OPT to avoid the configure script changing or augmenting it; I don't think that's the right thing. Should we make the effort to only set it if it wasn't set in the passed-in environment? Should we use re-arrange the addition of options to the compiler command line to use CPPFLAGS and CFLAGS instead, where the flags are not specific to optimization? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-04 16:41 Message: Logged In: YES user_id=3066 Should CFLAGS be handled in the same way? I'm really not sure. I'll see what the autoconf book says. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499656&group_id=5470 From noreply@sourceforge.net Sat Jan 5 08:04:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 00:04:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode and imp.find_module Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode and imp.find_module Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 00:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 02:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Sat Jan 5 10:53:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 02:53:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-498915 ] PyMapping_DelItemString doesn't exists Message-ID: Bugs item #498915, was opened at 2002-01-03 03:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jesús Cea Avión (jcea) Assigned to: Jeremy Hylton (jhylton) Summary: PyMapping_DelItemString doesn't exists Initial Comment: This bug seems related to https://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=476852 Python 2.2 here. "PyMapping_DelItemString" is really a macro (defined in "abstract.h") which delegates to "PyObject_DelItemString". The problem is that "PyObjectDelItemString" *DOESN'T* exists. I have changed my code to call PyDict_* routines instead the previous PyMapping_* to overcome this issue temporally. This is almost a "showstop" bug :-) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 02:53 Message: Logged In: YES user_id=21627 Thanks for your patch. It had a little too much code duplication for my taste, so I changed it to delegate to DelItem(). Committed as abstract.h 2.43 and 2.42.6.1, abstract.c 2.94 and 2.93.6.1. ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-01-03 10:48 Message: Logged In: YES user_id=97460 This patch should be studied by somebody familiar enough with Python inner working, buit it seems to run fine in my environment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:50 Message: Logged In: YES user_id=6380 Oops, you're right! Our apologies. A fix wouldn't be hard, but since we're all busy here with high priority stuff, it may take a while. If you can submit a patch, that would make things easier. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498915&group_id=5470 From noreply@sourceforge.net Sat Jan 5 11:00:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 03:00:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-498124 ] base64 mishandles binary on Win32 Message-ID: Bugs item #498124, was opened at 2001-12-31 09:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498124&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Roberts (timroberts) Assigned to: Nobody/Anonymous (nobody) Summary: base64 mishandles binary on Win32 Initial Comment: I'm using ActiveState Python 2.1.1 on Windows 2000 Service Pack 2, but I believe the problem happens on any recent Win32 Python. I use base64.py as a stand-alone tool for decoding Base64 attachments. This produces incorrect results with binary attachments on Win32, because it writes to sys.stdout, which is open in text mode by default. Thus, CR/LF and Ctrl-Z characters get botched. It is safe to assume that a base64 attachment will result in a binary file. A similar problem happens when encoding. The following patch towards the end of the test() function in base64.py should fix this. if o == '-t': test1(); return + if func == decode and sys.platform == 'win32': + import os, msvcrt + msvcrt.setmode( sys.stdout.fileno(), os.O_BINARY ) if args and args[0] != '-': ! func(open(args[0], 'rb'), sys.stdout) (Note I've changed 'r' to 'rb' in that last line; that's safe on Win32 and ignored on Linux.) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:00 Message: Logged In: YES user_id=21627 This is not a bug. base64 is not intended as a stand-alone program except for testing purposes. If you still need this feature, and cannot write your own script that imports base64, please submit a patch that accepts an optional second file argument. I'd rather not import msvcrt in this way in base64. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498124&group_id=5470 From noreply@sourceforge.net Sat Jan 5 11:03:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 03:03:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-498823 ] Misc/Makefile.pre.in missing Message-ID: Bugs item #498823, was opened at 2002-01-02 20:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 Category: Demos and Tools Group: Python 2.2 Status: Open Resolution: Duplicate Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Misc/Makefile.pre.in missing Initial Comment: The Demo/extend directory contains demo files which depend on the presence of Misc/Makefile.pre.in, which is missing from the distribution. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:03 Message: Logged In: YES user_id=21627 In this modified form (embedding docs talk about Makefile.pre.in), this is a duplicate of #497695. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 21:49 Message: Logged In: YES user_id=6380 OK, reopened and assigned to Fred. Fred, feel free to close this if you already have a reminder for that. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-01-02 21:33 Message: Logged In: YES user_id=52572 In case it's not already known: there are also lots of docs in the extending/embedding section which depend on that file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 20:59 Message: Logged In: YES user_id=6380 This was reported before, and has been fixed in CVS already. The Demo/extend directory is obsolete. Use the distutils package; docs are part of the standard 2.2 documentation bundle. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 From noreply@sourceforge.net Sat Jan 5 11:34:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 03:34:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-499169 ] imaplib.Time2Internaldate is broken Message-ID: Bugs item #499169, was opened at 2002-01-03 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib.Time2Internaldate is broken Initial Comment: The type tests in this function have stopped working because the return type of time.gmtime() and friends is now time.struct_time and not tuple. Secondly, the format string used for the timezone is '%+02d%02d'. I believe it should be '%+03d02d' since the first field width includes the sign character. A patch that works for me (note that it lets strftime do its own type-checking): --- imaplib.py~ Tue Oct 30 00:56:40 2001 +++ imaplib.py Thu Jan 3 18:42:22 2002 @@ -1070,13 +1070,12 @@ """ dttype = type(date_time) - if dttype is type(1) or dttype is type(1.1): + if dttype is str: + return date_time + if dttype is int or dttype is float: tt = time.localtime(date_time) - elif dttype is type(()): + else: tt = date_time - elif dttype is type(""): - return date_time # Assume in correct format - else: raise ValueError dt = time.strftime("%d-%b-%Y %H:%M:%S", tt) if dt[0] == '0': @@ -1085,7 +1084,7 @@ zone = -time.altzone else: zone = -time.timezone - return '"' + dt + " %+02d%02d" % divmod(zone/60, 60) + '"' + return '"' + dt + " %+03d%02d" % divmod(zone/60, 60) + '"' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:34 Message: Logged In: YES user_id=21627 Thanks for the report. I took a slightly different approach, since strftime raises TypeError in case of failure, whereas this function used to raise ValueError: so I know check for time.struct_time in addition to tuples. Committed as imaplib.py 1.40 and 1.39.8.1, test_imaplib.py 1.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 From noreply@sourceforge.net Sat Jan 5 11:42:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 03:42:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-499708 ] Int(long) causes Integer Overflow Message-ID: Bugs item #499708, was opened at 2002-01-04 19:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499708&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Int(long) causes Integer Overflow Initial Comment: In the spirit of unifying longs and ints, should int() be the sole way of truncating floats or should the programmer be responsible for categorizing and handling ints and longs separately? >>> int( 12341234123.4 ) Traceback (most recent call last): File "", line 1, in ? OverflowError: float too large to convert >>> def myint(f): ... try: ... return int(f) ... except OverflowError: ... return long(f) ... >>> myint( 12341234123.4 ) 12341234123L >>> myint(123.4) 123 I have one misgiving about fixing this one. assert type(int(x)) == int, 'should always succeed' would fail for when x=12341234123.4 The only way around this is to make longs return a IntType. Who knows what this would break. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:42 Message: Logged In: YES user_id=21627 See PEP 237. Python 2.2 finished phase A, where only operations are changed. Phase B.1 will address further semantic differences, such as the builtin int function (which will issue a warning if it returns a long where it previously behaved differently). So I'd conclude that, for Python 2.2, the behaviour you see is by design, and that this report should be closed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499708&group_id=5470 From noreply@sourceforge.net Sat Jan 5 12:05:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 04:05:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Sat Jan 5 15:24:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 07:24:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Sat Jan 5 21:41:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 13:41:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-498828 ] SyntaxError reports wrong module name Message-ID: Bugs item #498828, was opened at 2002-01-02 20:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498828&group_id=5470 Category: None Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Atsuo Ishimoto (atsuoi) Assigned to: Nobody/Anonymous (nobody) Summary: SyntaxError reports wrong module name Initial Comment: With Python 2.2, importing this module == xxx.py === def abcdefg(l): l.append("kfda" doesn't show module name 'xxx' in traceback info. >>> import xxx Traceback (most recent call last): File "", line 1, in ? File "", line 3 l.append("kfda" ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 13:41 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in parsetok.c 2.29 and 2.28.8.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498828&group_id=5470 From noreply@sourceforge.net Sun Jan 6 03:33:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 19:33:59 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-498855 ] add POST support to webbrowser module Message-ID: Feature Requests item #498855, was opened at 2002-01-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: add POST support to webbrowser module Initial Comment: This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed". ---------------------------------------------------------------------- >Comment By: Kevin Altis (kasplat) Date: 2002-01-05 19:33 Message: Logged In: YES user_id=228025 If you want to direct a user's browser to a web page that is the result of a POST. As I stated earlier, it is not always possible to get to the same page using GET. If this isn't possible on other browsers on other platforms then it might be best to just note this feature request in the webbrowser docs so that the issue isn't raised again. As mentioned earlier, a Windows script can always drive IE via COM or DDE if needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 11:08 Message: Logged In: YES user_id=6380 I still don't understand why you would need to do this. urllib supports POST. But the webbrowser module directs the user's browser to a website. Can you give an *example* of when you need this? Otherwise I'll just reject it -- I don't think this is possible anyway for most browsers except IE. ---------------------------------------------------------------------- Comment By: Kevin Altis (kasplat) Date: 2002-01-03 10:58 Message: Logged In: YES user_id=228025 If POST is not supported, there is a limit to the size of data that you can send; the limit will be different depending on each browser, but will always be less than 4K URL length limit. Many sites don't accept GET instead of POST for form data. Unfortunately, it is often difficult to tell whether a site accepts GET without changing the form manually and attempting a GET. Sometimes the reason that GET isn't accepted is do to lazy programming, but since a user can't do anything about that they still end up needing POST. Other times it is specifically because a site doesn't want the POST data to be cached. Any GET request will end up getting cached in proxies, show up in server logs, and also cached on the local client. All of these are bad from a security standpoint. POST data is never cached. This is not a critical addition to the webbrowser module, it simply makes it more complete. It is still possible to do POST another way and Windows programs can always drive Internet Explorer via COM or DDE, but I think POST in webbrowser would make a nice addition for the future. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:44 Message: Logged In: YES user_id=6380 Why would you need this? I find it hard to imagine a situation where I'd need this. Almost any forms that I would want to reach through webbrowser support GET anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 From noreply@sourceforge.net Sun Jan 6 03:45:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 19:45:12 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-498855 ] add POST support to webbrowser module Message-ID: Feature Requests item #498855, was opened at 2002-01-02 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: add POST support to webbrowser module Initial Comment: This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed". ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 19:45 Message: Logged In: YES user_id=6380 I'm still waiting for an *actual situation* where this need has arisen. ---------------------------------------------------------------------- Comment By: Kevin Altis (kasplat) Date: 2002-01-05 19:33 Message: Logged In: YES user_id=228025 If you want to direct a user's browser to a web page that is the result of a POST. As I stated earlier, it is not always possible to get to the same page using GET. If this isn't possible on other browsers on other platforms then it might be best to just note this feature request in the webbrowser docs so that the issue isn't raised again. As mentioned earlier, a Windows script can always drive IE via COM or DDE if needed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 11:08 Message: Logged In: YES user_id=6380 I still don't understand why you would need to do this. urllib supports POST. But the webbrowser module directs the user's browser to a website. Can you give an *example* of when you need this? Otherwise I'll just reject it -- I don't think this is possible anyway for most browsers except IE. ---------------------------------------------------------------------- Comment By: Kevin Altis (kasplat) Date: 2002-01-03 10:58 Message: Logged In: YES user_id=228025 If POST is not supported, there is a limit to the size of data that you can send; the limit will be different depending on each browser, but will always be less than 4K URL length limit. Many sites don't accept GET instead of POST for form data. Unfortunately, it is often difficult to tell whether a site accepts GET without changing the form manually and attempting a GET. Sometimes the reason that GET isn't accepted is do to lazy programming, but since a user can't do anything about that they still end up needing POST. Other times it is specifically because a site doesn't want the POST data to be cached. Any GET request will end up getting cached in proxies, show up in server logs, and also cached on the local client. All of these are bad from a security standpoint. POST data is never cached. This is not a critical addition to the webbrowser module, it simply makes it more complete. It is still possible to do POST another way and Windows programs can always drive Internet Explorer via COM or DDE, but I think POST in webbrowser would make a nice addition for the future. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-03 05:44 Message: Logged In: YES user_id=6380 Why would you need this? I find it hard to imagine a situation where I'd need this. Almost any forms that I would want to reach through webbrowser support GET anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470 From noreply@sourceforge.net Sun Jan 6 08:06:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Jan 2002 00:06:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Sun Jan 6 08:25:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Jan 2002 00:25:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-500078 ] Add built-in generator factory function Message-ID: Bugs item #500078, was opened at 2002-01-06 00:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500078&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add built-in generator factory function Initial Comment: Add factory function "generator" to built-ins. Used by itself, "generator" is short-hand for types.GeneratorType Used with a sequence argument, it produces a generator with the __iter__ and next() API. def generator( iterable ): for i in iterable: yield i g = generator( [1,2,3,4] ) h = generator( range(10) ) i = generator( xrange(10) ) j = generator( 'abcd' ) This parallels what was done with dict() and list() and other types. It allows easy type checking, ala, isinstance(j,generator). It helps coerce arguments when a function expects the __iter__ and next() API. For example: def xzip(*iterables): gens = map(generator, *iterables) while 1: yield tuple( [g.next() for g in gens] ) g = xzip( [1,2,3], range(20), xrange(5), genPrimes (10), getTimeStamp(), open("fil") ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500078&group_id=5470 From noreply@sourceforge.net Sun Jan 6 11:42:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Jan 2002 03:42:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-500115 ] "Extending" uses Makefile.pre.in Message-ID: Bugs item #500115, was opened at 2002-01-06 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500115&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: "Extending" uses Makefile.pre.in Initial Comment: The "Extending and Embedding the Python Interpreter" talks about Makefile.pre.in. Alas, that file is no longer available. I think it was a mistake to remove that file while the "Extending" document still refers to it; a year or two to switch over to the new distutils way of doing things would have been nice. Anyhow, http://www.python.org/doc/current/ext/building-on-unix.html should be updated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500115&group_id=5470 From noreply@sourceforge.net Sun Jan 6 17:17:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Jan 2002 09:17:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-499169 ] imaplib.Time2Internaldate is broken Message-ID: Bugs item #499169, was opened at 2002-01-03 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib.Time2Internaldate is broken Initial Comment: The type tests in this function have stopped working because the return type of time.gmtime() and friends is now time.struct_time and not tuple. Secondly, the format string used for the timezone is '%+02d%02d'. I believe it should be '%+03d02d' since the first field width includes the sign character. A patch that works for me (note that it lets strftime do its own type-checking): --- imaplib.py~ Tue Oct 30 00:56:40 2001 +++ imaplib.py Thu Jan 3 18:42:22 2002 @@ -1070,13 +1070,12 @@ """ dttype = type(date_time) - if dttype is type(1) or dttype is type(1.1): + if dttype is str: + return date_time + if dttype is int or dttype is float: tt = time.localtime(date_time) - elif dttype is type(()): + else: tt = date_time - elif dttype is type(""): - return date_time # Assume in correct format - else: raise ValueError dt = time.strftime("%d-%b-%Y %H:%M:%S", tt) if dt[0] == '0': @@ -1085,7 +1084,7 @@ zone = -time.altzone else: zone = -time.timezone - return '"' + dt + " %+02d%02d" % divmod(zone/60, 60) + '"' + return '"' + dt + " %+03d%02d" % divmod(zone/60, 60) + '"' ---------------------------------------------------------------------- >Comment By: Ben Hutchings (wom-work) Date: 2002-01-06 09:17 Message: Logged In: YES user_id=203860 In my opinion, raising ValueError when a value has the wrong type is also a bug, which is why I changed it. I think it's reasonable to change the (undocumented) exception type to a more sensible one while fixing the documented behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:34 Message: Logged In: YES user_id=21627 Thanks for the report. I took a slightly different approach, since strftime raises TypeError in case of failure, whereas this function used to raise ValueError: so I know check for time.struct_time in addition to tuples. Committed as imaplib.py 1.40 and 1.39.8.1, test_imaplib.py 1.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 From noreply@sourceforge.net Sun Jan 6 17:29:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Jan 2002 09:29:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-499169 ] imaplib.Time2Internaldate is broken Message-ID: Bugs item #499169, was opened at 2002-01-03 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib.Time2Internaldate is broken Initial Comment: The type tests in this function have stopped working because the return type of time.gmtime() and friends is now time.struct_time and not tuple. Secondly, the format string used for the timezone is '%+02d%02d'. I believe it should be '%+03d02d' since the first field width includes the sign character. A patch that works for me (note that it lets strftime do its own type-checking): --- imaplib.py~ Tue Oct 30 00:56:40 2001 +++ imaplib.py Thu Jan 3 18:42:22 2002 @@ -1070,13 +1070,12 @@ """ dttype = type(date_time) - if dttype is type(1) or dttype is type(1.1): + if dttype is str: + return date_time + if dttype is int or dttype is float: tt = time.localtime(date_time) - elif dttype is type(()): + else: tt = date_time - elif dttype is type(""): - return date_time # Assume in correct format - else: raise ValueError dt = time.strftime("%d-%b-%Y %H:%M:%S", tt) if dt[0] == '0': @@ -1085,7 +1084,7 @@ zone = -time.altzone else: zone = -time.timezone - return '"' + dt + " %+02d%02d" % divmod(zone/60, 60) + '"' + return '"' + dt + " %+03d%02d" % divmod(zone/60, 60) + '"' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-06 09:29 Message: Logged In: YES user_id=21627 We can do so for 2.3; for 2.2.1, changing the existing behaviour is not acceptable - it isn't clearly a bug, and applications may rely on the current exception. If you think action should be taken, please submit a patch (attaching the diff, instead of including it in the comment box) for imaplib.py and Misc/NEWS. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2002-01-06 09:17 Message: Logged In: YES user_id=203860 In my opinion, raising ValueError when a value has the wrong type is also a bug, which is why I changed it. I think it's reasonable to change the (undocumented) exception type to a more sensible one while fixing the documented behaviour. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:34 Message: Logged In: YES user_id=21627 Thanks for the report. I took a slightly different approach, since strftime raises TypeError in case of failure, whereas this function used to raise ValueError: so I know check for time.struct_time in addition to tuples. Committed as imaplib.py 1.40 and 1.39.8.1, test_imaplib.py 1.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499169&group_id=5470 From noreply@sourceforge.net Mon Jan 7 07:19:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Jan 2002 23:19:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-500078 ] Add built-in generator factory function Message-ID: Bugs item #500078, was opened at 2002-01-06 00:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500078&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Deleted Resolution: None >Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add built-in generator factory function Initial Comment: Add factory function "generator" to built-ins. Used by itself, "generator" is short-hand for types.GeneratorType Used with a sequence argument, it produces a generator with the __iter__ and next() API. def generator( iterable ): for i in iterable: yield i g = generator( [1,2,3,4] ) h = generator( range(10) ) i = generator( xrange(10) ) j = generator( 'abcd' ) This parallels what was done with dict() and list() and other types. It allows easy type checking, ala, isinstance(j,generator). It helps coerce arguments when a function expects the __iter__ and next() API. For example: def xzip(*iterables): gens = map(generator, *iterables) while 1: yield tuple( [g.next() for g in gens] ) g = xzip( [1,2,3], range(20), xrange(5), genPrimes (10), getTimeStamp(), open("fil") ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500078&group_id=5470 From noreply@sourceforge.net Mon Jan 7 10:43:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 02:43:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode and imp.find_module Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode and imp.find_module Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2002-01-07 02:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 00:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 02:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Mon Jan 7 10:55:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 02:55:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode and imp.find_module Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode and imp.find_module Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 02:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 02:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 00:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 02:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Mon Jan 7 13:09:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 05:09:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode and imp.find_module Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode and imp.find_module Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2002-01-07 05:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 02:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 02:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 00:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 02:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Mon Jan 7 14:28:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 06:28:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-500401 ] Security fix: webbrowser.py Message-ID: Bugs item #500401, was opened at 2002-01-07 06:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregor Hoffleit (flight) Assigned to: Nobody/Anonymous (nobody) Summary: Security fix: webbrowser.py Initial Comment: Chris Lawrence reports a security hole in webbrowser.py (cf. http://bugs.debian.org/127507 for the full report): webbrowser.py doesn't escape the URL when calling the browser through os.system(). This makes it possible for an attacker to execute arbitrary code in /bin/sh. Attached is a patch by Chris that closes the holes. Gregor ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 From noreply@sourceforge.net Mon Jan 7 14:30:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 06:30:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-500401 ] Security fix: webbrowser.py Message-ID: Bugs item #500401, was opened at 2002-01-07 06:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Gregor Hoffleit (flight) Assigned to: Nobody/Anonymous (nobody) Summary: Security fix: webbrowser.py Initial Comment: Chris Lawrence reports a security hole in webbrowser.py (cf. http://bugs.debian.org/127507 for the full report): webbrowser.py doesn't escape the URL when calling the browser through os.system(). This makes it possible for an attacker to execute arbitrary code in /bin/sh. Attached is a patch by Chris that closes the holes. Gregor ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 From noreply@sourceforge.net Mon Jan 7 15:09:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 07:09:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-500401 ] Security fix: webbrowser.py Message-ID: Bugs item #500401, was opened at 2002-01-07 06:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 9 Submitted By: Gregor Hoffleit (flight) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Security fix: webbrowser.py Initial Comment: Chris Lawrence reports a security hole in webbrowser.py (cf. http://bugs.debian.org/127507 for the full report): webbrowser.py doesn't escape the URL when calling the browser through os.system(). This makes it possible for an attacker to execute arbitrary code in /bin/sh. Attached is a patch by Chris that closes the holes. Gregor ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-07 07:09 Message: Logged In: YES user_id=6380 Let's also get the fix into 2.1.2 and 2.2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 From noreply@sourceforge.net Mon Jan 7 15:32:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 07:32:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-500401 ] Security fix: webbrowser.py Message-ID: Bugs item #500401, was opened at 2002-01-07 06:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Gregor Hoffleit (flight) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Security fix: webbrowser.py Initial Comment: Chris Lawrence reports a security hole in webbrowser.py (cf. http://bugs.debian.org/127507 for the full report): webbrowser.py doesn't escape the URL when calling the browser through os.system(). This makes it possible for an attacker to execute arbitrary code in /bin/sh. Attached is a patch by Chris that closes the holes. Gregor ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-07 07:32 Message: Logged In: YES user_id=3066 Fixed in Lib/webbrowser.py 1.27, 1.26.6.1, and 1.18.2.3 (to be part of Python versions 2.1.2, 2.2.1, and 2.3). Would someone who understands the Debian bug reporting system please pass the word to them? Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-07 07:09 Message: Logged In: YES user_id=6380 Let's also get the fix into 2.1.2 and 2.2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500401&group_id=5470 From noreply@sourceforge.net Mon Jan 7 16:24:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 08:24:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-476326 ] Unicode in sys.path not supported Message-ID: Bugs item #476326, was opened at 2001-10-30 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Paul Boddie (pboddie) Assigned to: M.-A. Lemburg (lemburg) >Summary: Unicode in sys.path not supported Initial Comment: When a Unicode string is passed as the module name to imp.find_module, the function fails to import the named module even when it exists in the specified path, returning the error message "No module named ..." as a result. The problem in Python 2.0 can be traced to line 922 of Python/import.c which ensures that any strings involved in the find_module function must be standard Python strings and not Unicode strings, since it tests the type of path components against &PyString_Type explicitly. Interestingly, the __import__ built-in function seems to work with Unicode strings. Either way, it would be great if this could be documented or even fixed, but I don't know what the policy is on Unicode module names (even when they only contain ASCII-compatible characters). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 05:09 Message: Logged In: YES user_id=226443 My apologies: I should have been clearer in my description. Here's a test case for Python 2.1 on Windows which demonstrates the problem: import sys, imp ascii_dir = "D:\Private\Vaults" unicode_dir = u"D:\Private\Vaults" # First test: Unicode sys.path value. sys.path.append(unicode_dir) imp.find_module(u"VaultsSearch") # fails imp.find_module("VaultsSearch") # fails sys.path.remove(unicode_dir) # Second test: ASCII sys.path value. sys.path.append(ascii_dir) imp.find_module(u"VaultsSearch") # succeeds imp.find_module("VaultsSearch") # succeeds sys.path.remove(ascii_dir) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-07 02:55 Message: Logged In: YES user_id=38388 The find_module() code doesn't seem to have changed between the releases, so it should work in Python 2.0 as well. The only parts I see in the source code which require strings are the sys.path handling APIs. The optional second argument to find_module() will also only accept strings. Perhaps that's where your problem originated ? Python 2.0 (#1, Jan 19 2001, 17:54:27) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module(u'platform') (, '/home/lemburg/bin/platform.py', ('.py', 'r', 1)) > Can you give an example which demonstrates the problem ? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2002-01-07 02:43 Message: Logged In: YES user_id=226443 It must have been fixed between Python 2.0 and Python 2.1, then, but I can't find any obvious indication of this in Python/import.c. The platform probably shouldn't matter in this case, but I was using Red Hat Linux 6.1 on Intel. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 00:04 Message: Logged In: YES user_id=21627 I cannot reproduce the problem in Python 2.1: >>> import imp >>> imp.find_module(u"string") (, '/usr/local/lib/python2.2/string.py', ('.py', 'r', 1)) I don't think __import__ should accept non-ASCII names. It may be reasonable to further restrict import to verify that the argument is a NAME, in the sense of the Python lexis; doing so is not important, either. I cannot see any further problem in this report, so I suggest to close it as fixed. The test in line 922 only checks the path, not the module name. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2001-12-03 02:59 Message: Logged In: YES user_id=226443 For my purposes, I just wrapped the module name in a 'str' function call. I had Unicode strings because I was using text from an XML document and then attempting to use such text with the import mechanism. One issue is whether Python would ever support importing from files which have non-ASCII filenames. I can imagine that certain operating systems support Unicode filenames, for example, but then the Python language probably doesn't support such filenames as the basis for module names when used with the 'import' statement and other related statements. So, there's a wider issue of text encodings in (C)Python scripts as part of the "comprehensive" solution to this problem; the easy solution is just to enforce ASCII-only module names. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-01 15:01 Message: Logged In: YES user_id=38388 I guess Python should not except non-ASCII module names, so conversion of Unicode to ASCII should be appropriate. Would it suffice to only test this in find_module() or do you think that I need to dig deeper into the import mechanism ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476326&group_id=5470 From noreply@sourceforge.net Mon Jan 7 16:26:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 08:26:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-500441 ] PyObject_DelItemString missing Message-ID: Bugs item #500441, was opened at 2002-01-07 08:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500441&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jose Vasconcellos (matein4) Assigned to: Nobody/Anonymous (nobody) Summary: PyObject_DelItemString missing Initial Comment: The PyObject_DelItemString declaration is missing from abstract.h. There is a macro PyMapping_DelItemString that references it but there is no definition. Note, under python 2.1 PyMapping_DelItemString was set to PyDict_DelItemString. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500441&group_id=5470 From noreply@sourceforge.net Mon Jan 7 18:46:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 10:46:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-500508 ] problems printing multipart MIME msg Message-ID: Bugs item #500508, was opened at 2002-01-07 10:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500508&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry Warsaw (bwarsaw) Summary: problems printing multipart MIME msg Initial Comment: Got this from python-help. A user there is trying to use the email module to display multipart MIME messages generated by mutt. Attached is a specific mail message. Using this simple script >>> import email >>> f = open("spam1") >>> msg=email.message_from_file(f) >>> print msg generates this traceback Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/email/Message.py", line 49, in __str__ return self.as_string(unixfrom=1) File "/usr/local/lib/python2.2/email/Message.py", line 59, in as_string g(self, unixfrom=unixfrom) File "/usr/local/lib/python2.2/email/Generator.py", line 83, in __call__ self._write(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 104, in _write self._dispatch(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 134, in _dispatch meth(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 243, in _handle_multipart g(part, unixfrom=0) File "/usr/local/lib/python2.2/email/Generator.py", line 83, in __call__ self._write(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 104, in _write self._dispatch(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 134, in _dispatch meth(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 310, in _handle_message g(msg.get_payload(), unixfrom=0) File "/usr/local/lib/python2.2/email/Generator.py", line 83, in __call__ self._write(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 104, in _write self._dispatch(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 134, in _dispatch meth(msg) File "/usr/local/lib/python2.2/email/Generator.py", line 240, in _handle_multipart for part in msg.get_payload(): File "/usr/local/lib/python2.2/email/Message.py", line 151, in __getitem__ return self.get(name) File "/usr/local/lib/python2.2/email/Message.py", line 214, in get name = name.lower() AttributeError: 'int' object has no attribute 'lower' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500508&group_id=5470 From noreply@sourceforge.net Mon Jan 7 20:15:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 12:15:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2 Message-ID: Bugs item #500539, was opened at 2002-01-07 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inaccuracy(?) in tutorial section 9.2 Initial Comment: Section 9.2 paragraph 3 defines a namespace as a mapping from names to objects. Perhaps I'm being picky here, but isn't a namespace a mapping from names to object references? For example, doesn't executing the expression "modname.the_answer = 42" as shown in paragraph 5 cause modname.the_answer to refer to a different object than the one to which it referred previously, rather than affecting the specific object to which modname.the_answer refers? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 From noreply@sourceforge.net Mon Jan 7 21:32:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 13:32:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-500595 ] gettext.install behaves strange Message-ID: Bugs item #500595, was opened at 2002-01-07 13:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500595&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Rittau (srittau) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.install behaves strange Initial Comment: This is a copy of a bug I sent to the Debian BTS (bug number #127954): --------------------------------------- The behaviour of the gettext.install function is broken in Python 2.1 as well as 2.2. Whenever it tries to open a message catalog that does not exist, an exception is thrown and _ does not get installed in the standard namespace. Consider: srittau@jroger:~$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import gettext >>> gettext.install('foo') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/gettext.py", line 251, in install translation(domain, localedir).install(unicode) File "/usr/lib/python2.1/gettext.py", line 238, in translation raise IOError(ENOENT, 'No translation file found for domain', domain) IOError: [Errno 2] No translation file found for domain: 'foo' >>> This does even happen if I set LANG to C! Now, I would expect python to continue if a message catalog is not found, as does every other program I know of. A missing catalog is certainly not a critical error. It should at least install _ in the standard name space and throw a custom exception that I can easily ignore if the catalog was not found. I can workaround this behaviour by catching the IOError exception and installing _ in the standard name space by hand. But that's certainly not the solution. --------------------------------------- The Debian maintainer suggested that I bring this up here. He also believes that this is a documentation bug, since this behaviour is documented for gettext.translation(), but not for gettext.install(). But I still believe that this behaviour is wrong, since not finding a translation file is the common case and you will want to continue to use your program and just use the internal strings. - Sebastian ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500595&group_id=5470 From noreply@sourceforge.net Mon Jan 7 22:28:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 14:28:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-500626 ] round (,) errors? Message-ID: Bugs item #500626, was opened at 2002-01-07 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500626&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Kennedy (kennedyp) Assigned to: Nobody/Anonymous (nobody) Summary: round (,) errors? Initial Comment: >From my Win2K Pro/SP1 interactive session: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a=3.1415928*7*7 >>> a 153.9380472 >>> round (a,2) 153.94 >>> round (a,1) 153.90000000000001 >>> round (a,3) 153.93799999999999 >>> round (a,4) 153.93799999999999 >>> round (a,5) 153.93805 >>> round (a,6) 153.93804700000001 >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500626&group_id=5470 From noreply@sourceforge.net Mon Jan 7 22:59:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 14:59:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-500441 ] PyObject_DelItemString missing Message-ID: Bugs item #500441, was opened at 2002-01-07 08:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500441&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jose Vasconcellos (matein4) Assigned to: Nobody/Anonymous (nobody) Summary: PyObject_DelItemString missing Initial Comment: The PyObject_DelItemString declaration is missing from abstract.h. There is a macro PyMapping_DelItemString that references it but there is no definition. Note, under python 2.1 PyMapping_DelItemString was set to PyDict_DelItemString. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-07 14:59 Message: Logged In: YES user_id=6380 Dup of #498915. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500441&group_id=5470 From noreply@sourceforge.net Tue Jan 8 01:01:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 17:01:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-495624 ] Error building info docs Message-ID: Bugs item #495624, was opened at 2001-12-20 13:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Error building info docs Initial Comment: make info fails ... Element.pm is from the (Debian) package libhtml-tree- perl, version 3.11. Any hints, what's wrong? $ make info cd info && make make[1]: Entering directory `/export/swt- dev/users/doko/packages/python2.2/python2.2- 2.1.99c1/Doc/info' ../tools/mkinfo ../html/api/api.html perl - I/home/swt/doko/export/packages/python2.2/python2.2- 2.1.99c1/Doc/tools /home/swt/doko/export/packages/pytho n2.2/python2.2- 2.1.99c1/Doc/tools/html2texi.pl /home/swt/doko/export/p ackages/python2.2/python2.2- 2.1.99c1/Doc/html/api/api.html /usr/share/perl5/HTML/Element.pm:2091: function main::output_body expected 3 arguments, got 5: Guido van Rossum 1 4 HTML::Element=HASH(0x82c479c) 0 make[1]: *** [python-api.info] Error 255 make[1]: Leaving directory `/export/swt- dev/users/doko/packages/python2.2/python2.2- 2.1.99c1/Doc/info' make: *** [info] Error 2 ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-01-07 17:01 Message: Logged In: YES user_id=60903 Found updated versions of the conversion scripts http://pag.lcs.mit.edu/~mernst/software/#html2texi http://pag.lcs.mit.edu/~mernst/software/#checkargs with http://pag.lcs.mit.edu/~mernst/software/python-info- Makefile from the same site I get a step further ... fixinfo.el is out of date ... who is pdm/pdm, who builds the info tarballs for download? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470 From noreply@sourceforge.net Tue Jan 8 02:48:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 18:48:19 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-500698 ] Taint a la Perl? Message-ID: Feature Requests item #500698, was opened at 2002-01-07 18:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Priority: 5 Submitted By: Peter Scott (sketerpot) Assigned to: Nobody/Anonymous (nobody) Summary: Taint a la Perl? Initial Comment: This might just add unnecessary bloat, but since Python is being used in CGI scripts, it can be used to narrow a security hole. One way of breaking security is for a naiive programmer (don't try to deny their existance) to run an arbitrary command from the page viewer. Perl has developed an interesting mechanism for helping with this: taint. The way it works is, when something comes directly from the user, like a key in a form, it is considered to have taint unless specifically untainted. Things like os.exec() would create a warning message if you passed tainted strings to them. As I said, this might just add unnecessary bloat, but for an option that can be left out for most builds of Python I think it would be pretty nice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470 From noreply@sourceforge.net Tue Jan 8 03:27:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 19:27:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-500704 ] Tutorial does not describe nested scope Message-ID: Bugs item #500704, was opened at 2002-01-07 19:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500704&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Pierre Rouleau (pierre_rouleau) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tutorial does not describe nested scope Initial Comment: The current copy of the tuturial for Python 2.2 states, in chapter 9.2 (Python Scopes and Name Spaces): """Although scopes are determined statically, they are used dynamically. At any time during execution, exactly three nested scopes are in use (exactly three namespaces are directly accessible): the innermost scope, which is searched first, contains the local names, the middle scope, searched next, contains the current module's global names, and the outermost scope (searched last) is the namespace containing built-in names.""" I believe the above text should be updated to reflect the fact that Python 2.2 supports nested scopes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500704&group_id=5470 From noreply@sourceforge.net Tue Jan 8 03:28:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 19:28:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-500705 ] os.listdir("") bug on Windows Message-ID: Bugs item #500705, was opened at 2002-01-07 19:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500705&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir("") bug on Windows Initial Comment: There is an out-of-bounds error on Windows when using os.listdir("") which could result in indeterminate behaviour. After parsing the args, it does ch = namebuf[len-1]; which indexes before the array as len = 0. Possibly change this to ch = (len > 0) ? namebuf[len-1] : '\0'; ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500705&group_id=5470 From noreply@sourceforge.net Tue Jan 8 09:00:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 01:00:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) >Assigned to: Skip Montanaro (montanaro) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Tue Jan 8 15:20:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 07:20:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2 Message-ID: Bugs item #500539, was opened at 2002-01-07 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 Category: Documentation >Group: Not a Bug >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inaccuracy(?) in tutorial section 9.2 Initial Comment: Section 9.2 paragraph 3 defines a namespace as a mapping from names to objects. Perhaps I'm being picky here, but isn't a namespace a mapping from names to object references? For example, doesn't executing the expression "modname.the_answer = 42" as shown in paragraph 5 cause modname.the_answer to refer to a different object than the one to which it referred previously, rather than affecting the specific object to which modname.the_answer refers? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 07:20 Message: Logged In: YES user_id=3066 There is no difference between an object reference and an object in Python code, so the statement in the tutorial is correct. The behavior you are describing as "object" behavior seems to assume that there's some sort of assignment which mutates the object which is the current value of the assignment target, but there is no such operator. I can see where this might be confusing for programmers coming from C++, though. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 From noreply@sourceforge.net Tue Jan 8 16:22:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 08:22:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2 Message-ID: Bugs item #500539, was opened at 2002-01-07 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 Category: Documentation Group: Not a Bug Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inaccuracy(?) in tutorial section 9.2 Initial Comment: Section 9.2 paragraph 3 defines a namespace as a mapping from names to objects. Perhaps I'm being picky here, but isn't a namespace a mapping from names to object references? For example, doesn't executing the expression "modname.the_answer = 42" as shown in paragraph 5 cause modname.the_answer to refer to a different object than the one to which it referred previously, rather than affecting the specific object to which modname.the_answer refers? ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2002-01-08 08:22 Message: Logged In: YES user_id=418174 Actually, I was saying the opposite. Executing "x = 42" certainly does not mutate the object that was previously associated with x, but rather causes x to be associated with a new object, namely 42. To me that suggests that 42 is an object and x is something else, perhaps a way of accessing an object. You are right that this kind of confusion is common among people who write about C++, but you are not right that I used C++ as the basis for my original comment. I first became aware of the importance of distinguishing between objects and object references in Algol 68, many years before C++ ever existed, and there is a wonderful piece in Lewis Carroll's ``Through the Looking Glass'' about this very issue. More seriously, if there is no program I can ever write that is capable of distinguishing between an object and an object reference, then it doesn't matter. However, I think I can write such a program: a = [42]; b = [a, a] Now it doesn't make sense to say that b[0] and b[1] are the same object, because they aren't. Proof: If I execute b[0]=79, b[1] is still [42]. On the other hand, b[0] and b[1] do refer to the same object, and it is that distinction that I am suggesting that it is important to draw. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 07:20 Message: Logged In: YES user_id=3066 There is no difference between an object reference and an object in Python code, so the statement in the tutorial is correct. The behavior you are describing as "object" behavior seems to assume that there's some sort of assignment which mutates the object which is the current value of the assignment target, but there is no such operator. I can see where this might be confusing for programmers coming from C++, though. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 From noreply@sourceforge.net Tue Jan 8 16:49:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 08:49:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2 Message-ID: Bugs item #500539, was opened at 2002-01-07 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 Category: Documentation Group: Not a Bug >Status: Open Resolution: Works For Me >Priority: 6 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inaccuracy(?) in tutorial section 9.2 Initial Comment: Section 9.2 paragraph 3 defines a namespace as a mapping from names to objects. Perhaps I'm being picky here, but isn't a namespace a mapping from names to object references? For example, doesn't executing the expression "modname.the_answer = 42" as shown in paragraph 5 cause modname.the_answer to refer to a different object than the one to which it referred previously, rather than affecting the specific object to which modname.the_answer refers? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 08:49 Message: Logged In: YES user_id=3066 Re-opened for further consideration when I have more time. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-01-08 08:22 Message: Logged In: YES user_id=418174 Actually, I was saying the opposite. Executing "x = 42" certainly does not mutate the object that was previously associated with x, but rather causes x to be associated with a new object, namely 42. To me that suggests that 42 is an object and x is something else, perhaps a way of accessing an object. You are right that this kind of confusion is common among people who write about C++, but you are not right that I used C++ as the basis for my original comment. I first became aware of the importance of distinguishing between objects and object references in Algol 68, many years before C++ ever existed, and there is a wonderful piece in Lewis Carroll's ``Through the Looking Glass'' about this very issue. More seriously, if there is no program I can ever write that is capable of distinguishing between an object and an object reference, then it doesn't matter. However, I think I can write such a program: a = [42]; b = [a, a] Now it doesn't make sense to say that b[0] and b[1] are the same object, because they aren't. Proof: If I execute b[0]=79, b[1] is still [42]. On the other hand, b[0] and b[1] do refer to the same object, and it is that distinction that I am suggesting that it is important to draw. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 07:20 Message: Logged In: YES user_id=3066 There is no difference between an object reference and an object in Python code, so the statement in the tutorial is correct. The behavior you are describing as "object" behavior seems to assume that there's some sort of assignment which mutates the object which is the current value of the assignment target, but there is no such operator. I can see where this might be confusing for programmers coming from C++, though. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 From noreply@sourceforge.net Tue Jan 8 17:35:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 09:35:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Tue Jan 8 20:10:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 12:10:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2 Message-ID: Bugs item #500539, was opened at 2002-01-07 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: Works For Me >Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inaccuracy(?) in tutorial section 9.2 Initial Comment: Section 9.2 paragraph 3 defines a namespace as a mapping from names to objects. Perhaps I'm being picky here, but isn't a namespace a mapping from names to object references? For example, doesn't executing the expression "modname.the_answer = 42" as shown in paragraph 5 cause modname.the_answer to refer to a different object than the one to which it referred previously, rather than affecting the specific object to which modname.the_answer refers? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:10 Message: Logged In: YES user_id=6380 I read everything. :-) Let me butt in here. (I also probably wrote that section in the tutorial. :-) I know Algol-68 and am familiar with its use of the term "reference". Fred probably isn't and thinks of references as equivalent to pointers; but I'm sure he's familiar with the C term "l-value" which is C's name for what Algol-68 cals a reference. (I don't know what C++ calls it these days; isn't reference a specific thing involving an & operator there?) Python just doesn't use the concept of "object reference" in the same way as Algol-68 uses it. I mean it when I say that a namespace maps names to objects! The difference is that I consider assignment a change to the mapping. It can't be a change to a "reference" (in the Algol-68 sense) since the reference may not yet exist (if the name wasn't bound before). Also, Python *definitely* doesn't have the concept of a reference to a reference (C's ** types, Algol-68's ref ref). While there most definitely is a piece of memory holding an object pointer in the *implementation* of Python's namespaces, and in other collections of objects like lists, there's no way in Python to talk about that piece of memory in a unified way. You'd have to say "the name X in mapping Y" or "the index K in sequence L" or something like that. I hope this helps everyone's understanding! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 08:49 Message: Logged In: YES user_id=3066 Re-opened for further consideration when I have more time. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-01-08 08:22 Message: Logged In: YES user_id=418174 Actually, I was saying the opposite. Executing "x = 42" certainly does not mutate the object that was previously associated with x, but rather causes x to be associated with a new object, namely 42. To me that suggests that 42 is an object and x is something else, perhaps a way of accessing an object. You are right that this kind of confusion is common among people who write about C++, but you are not right that I used C++ as the basis for my original comment. I first became aware of the importance of distinguishing between objects and object references in Algol 68, many years before C++ ever existed, and there is a wonderful piece in Lewis Carroll's ``Through the Looking Glass'' about this very issue. More seriously, if there is no program I can ever write that is capable of distinguishing between an object and an object reference, then it doesn't matter. However, I think I can write such a program: a = [42]; b = [a, a] Now it doesn't make sense to say that b[0] and b[1] are the same object, because they aren't. Proof: If I execute b[0]=79, b[1] is still [42]. On the other hand, b[0] and b[1] do refer to the same object, and it is that distinction that I am suggesting that it is important to draw. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 07:20 Message: Logged In: YES user_id=3066 There is no difference between an object reference and an object in Python code, so the statement in the tutorial is correct. The behavior you are describing as "object" behavior seems to assume that there's some sort of assignment which mutates the object which is the current value of the assignment target, but there is no such operator. I can see where this might be confusing for programmers coming from C++, though. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 From noreply@sourceforge.net Tue Jan 8 20:13:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 12:13:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build >Group: Python 2.2.1 candidate Status: Open Resolution: None >Priority: 7 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Tue Jan 8 20:27:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 12:27:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2 Message-ID: Bugs item #500539, was opened at 2002-01-07 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: Works For Me Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Inaccuracy(?) in tutorial section 9.2 Initial Comment: Section 9.2 paragraph 3 defines a namespace as a mapping from names to objects. Perhaps I'm being picky here, but isn't a namespace a mapping from names to object references? For example, doesn't executing the expression "modname.the_answer = 42" as shown in paragraph 5 cause modname.the_answer to refer to a different object than the one to which it referred previously, rather than affecting the specific object to which modname.the_answer refers? ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2002-01-08 12:27 Message: Logged In: YES user_id=418174 Aha! -- Now I understand. You're thinking of a namespace as a collection of named references to objects that can be searched associatively by name :-) Moreover, the name- reference relation is bijective. That is, if I write a = 3 b = 4 then there is a unique entity -- which I have been calling a reference -- associated with `a' and another such entity associated with `b'. Moreover, because the relation is bijective, the entity with which `a' is associated is not associated with any other name, and similarly for `b'. Because of this bijectivity, there is never any reason to think about this entity separately from its name, and therefore you do not need a separate term for it. Incidentally, C++ uses both the term `lvalue' and `reference,' with `lvalue' denoting a syntactic context and `reference' denoting a particular property of types. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:10 Message: Logged In: YES user_id=6380 I read everything. :-) Let me butt in here. (I also probably wrote that section in the tutorial. :-) I know Algol-68 and am familiar with its use of the term "reference". Fred probably isn't and thinks of references as equivalent to pointers; but I'm sure he's familiar with the C term "l-value" which is C's name for what Algol-68 cals a reference. (I don't know what C++ calls it these days; isn't reference a specific thing involving an & operator there?) Python just doesn't use the concept of "object reference" in the same way as Algol-68 uses it. I mean it when I say that a namespace maps names to objects! The difference is that I consider assignment a change to the mapping. It can't be a change to a "reference" (in the Algol-68 sense) since the reference may not yet exist (if the name wasn't bound before). Also, Python *definitely* doesn't have the concept of a reference to a reference (C's ** types, Algol-68's ref ref). While there most definitely is a piece of memory holding an object pointer in the *implementation* of Python's namespaces, and in other collections of objects like lists, there's no way in Python to talk about that piece of memory in a unified way. You'd have to say "the name X in mapping Y" or "the index K in sequence L" or something like that. I hope this helps everyone's understanding! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 08:49 Message: Logged In: YES user_id=3066 Re-opened for further consideration when I have more time. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-01-08 08:22 Message: Logged In: YES user_id=418174 Actually, I was saying the opposite. Executing "x = 42" certainly does not mutate the object that was previously associated with x, but rather causes x to be associated with a new object, namely 42. To me that suggests that 42 is an object and x is something else, perhaps a way of accessing an object. You are right that this kind of confusion is common among people who write about C++, but you are not right that I used C++ as the basis for my original comment. I first became aware of the importance of distinguishing between objects and object references in Algol 68, many years before C++ ever existed, and there is a wonderful piece in Lewis Carroll's ``Through the Looking Glass'' about this very issue. More seriously, if there is no program I can ever write that is capable of distinguishing between an object and an object reference, then it doesn't matter. However, I think I can write such a program: a = [42]; b = [a, a] Now it doesn't make sense to say that b[0] and b[1] are the same object, because they aren't. Proof: If I execute b[0]=79, b[1] is still [42]. On the other hand, b[0] and b[1] do refer to the same object, and it is that distinction that I am suggesting that it is important to draw. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-08 07:20 Message: Logged In: YES user_id=3066 There is no difference between an object reference and an object in Python code, so the statement in the tutorial is correct. The behavior you are describing as "object" behavior seems to assume that there's some sort of assignment which mutates the object which is the current value of the assignment target, but there is no such operator. I can see where this might be confusing for programmers coming from C++, though. ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470 From noreply@sourceforge.net Tue Jan 8 21:03:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 13:03:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Skip Montanaro (montanaro) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Tue Jan 8 21:17:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 13:17:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-501022 ] Python/Tkinter crashes Message-ID: Bugs item #501022, was opened at 2002-01-08 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501022&group_id=5470 Category: Tkinter Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: John W Lewis (lewisjwl) Assigned to: Nobody/Anonymous (nobody) Summary: Python/Tkinter crashes Initial Comment: Good morning This issue was reported earlier, but I could not provide a concrete example. The following little program crashes under Windows 2000 Pro, but not on UNIX. My PC has 2GB of memory and the program is using much less than that. It appears to be exhausting some fixed resource (a heap?). Microsoft will debug the problem if they can analyze the dump file to isolate the specific system calls which exhaust that resource. Right now all they can tell is that the fault occurs somewhere in Tkinter. They have asked me to provide the following: * Dr Watson dump file * MPS profile * perfmon log How should I proceed? How can I get a PC version of python with a full symbol table for debugging? Regards John Lewis jlewis9@csc.com 443-562-4945 cell ----------------------------------------------------------------------------------- ## PROGRAM: crash.py ## HISTORY: jw lewis, 1/8/01 ## OBJECTIVE ## Write a program which causes Tkinter to fail abnormally in Windows from Tkinter import * root = Tk() log = open("log.txt","w") ## Force crash by generating too many PhotoImage objects images = [] for i in xrange(0,10000): if i>9900: log.write( str(i)+"\n" ) log.flush() image = PhotoImage() image.put("blue") images.append( image ) ----------------------------------------------------------------------------------- Resulting log.txt file 9901 9902 9903 ... 9950 9951 9952 9953 9954 9955 9956 9957 9958 9959 CRASH ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501022&group_id=5470 From noreply@sourceforge.net Tue Jan 8 21:36:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 13:36:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-501022 ] Python/Tkinter crashes Message-ID: Bugs item #501022, was opened at 2002-01-08 13:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501022&group_id=5470 Category: Tkinter Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: John W Lewis (lewisjwl) Assigned to: Nobody/Anonymous (nobody) Summary: Python/Tkinter crashes Initial Comment: Good morning This issue was reported earlier, but I could not provide a concrete example. The following little program crashes under Windows 2000 Pro, but not on UNIX. My PC has 2GB of memory and the program is using much less than that. It appears to be exhausting some fixed resource (a heap?). Microsoft will debug the problem if they can analyze the dump file to isolate the specific system calls which exhaust that resource. Right now all they can tell is that the fault occurs somewhere in Tkinter. They have asked me to provide the following: * Dr Watson dump file * MPS profile * perfmon log How should I proceed? How can I get a PC version of python with a full symbol table for debugging? Regards John Lewis jlewis9@csc.com 443-562-4945 cell ----------------------------------------------------------------------------------- ## PROGRAM: crash.py ## HISTORY: jw lewis, 1/8/01 ## OBJECTIVE ## Write a program which causes Tkinter to fail abnormally in Windows from Tkinter import * root = Tk() log = open("log.txt","w") ## Force crash by generating too many PhotoImage objects images = [] for i in xrange(0,10000): if i>9900: log.write( str(i)+"\n" ) log.flush() image = PhotoImage() image.put("blue") images.append( image ) ----------------------------------------------------------------------------------- Resulting log.txt file 9901 9902 9903 ... 9950 9951 9952 9953 9954 9955 9956 9957 9958 9959 CRASH ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:36 Message: Logged In: YES user_id=21627 As I mentioned before, my best guess is that it runs out of bitmap handles. Anyway, download the Python source code, and read the document in PCbuild/readme.txt to find out how to generate debugging information. You may want to build tcl/tk with debugging as well, but I don't know how to do that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501022&group_id=5470 From noreply@sourceforge.net Tue Jan 8 21:55:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 13:55:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 7 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:55 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in the extension modules. According to POSIX, an implementation (i.e. OS and C compiler) shall define _POSIX_THREADS in if threads are supported. Python 2.1 was always defining this, which was an error because it might have conflicted with the operating system settings. Python 2.2 only defines it if it finds a specific bug in the implementation: namely, if the system provides posix threads, but does not declare so in unistd.h. So the bug is in the extension modules: they must include to get _POSIX_THREADS. It is safe to include after including Python.h and checking HAVE_UNISTD_H. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Tue Jan 8 21:57:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 13:57:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-500626 ] round (,) errors? Message-ID: Bugs item #500626, was opened at 2002-01-07 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500626&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Patrick Kennedy (kennedyp) Assigned to: Nobody/Anonymous (nobody) Summary: round (,) errors? Initial Comment: >From my Win2K Pro/SP1 interactive session: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a=3.1415928*7*7 >>> a 153.9380472 >>> round (a,2) 153.94 >>> round (a,1) 153.90000000000001 >>> round (a,3) 153.93799999999999 >>> round (a,4) 153.93799999999999 >>> round (a,5) 153.93805 >>> round (a,6) 153.93804700000001 >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:57 Message: Logged In: YES user_id=21627 This is not a bug in Python, see http://www.python.org/doc/FAQ.html#4.98 153.94 cannot be represented exactly in your computer, so Pyton won't claim it can. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500626&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:02:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:02:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Skip Montanaro (montanaro) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:04:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:04:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-500115 ] "Extending" uses Makefile.pre.in Message-ID: Bugs item #500115, was opened at 2002-01-06 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500115&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: "Extending" uses Makefile.pre.in Initial Comment: The "Extending and Embedding the Python Interpreter" talks about Makefile.pre.in. Alas, that file is no longer available. I think it was a mistake to remove that file while the "Extending" document still refers to it; a year or two to switch over to the new distutils way of doing things would have been nice. Anyhow, http://www.python.org/doc/current/ext/building-on-unix.html should be updated. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:04 Message: Logged In: YES user_id=21627 A patch for that is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500115&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:05:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:05:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 7 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 14:05 Message: Logged In: YES user_id=6380 Can't we #include in Python.h, if it exists? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:55 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in the extension modules. According to POSIX, an implementation (i.e. OS and C compiler) shall define _POSIX_THREADS in if threads are supported. Python 2.1 was always defining this, which was an error because it might have conflicted with the operating system settings. Python 2.2 only defines it if it finds a specific bug in the implementation: namely, if the system provides posix threads, but does not declare so in unistd.h. So the bug is in the extension modules: they must include to get _POSIX_THREADS. It is safe to include after including Python.h and checking HAVE_UNISTD_H. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:06:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:06:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-497697 ] building shared modules Message-ID: Bugs item #497697, was opened at 2001-12-29 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 Category: Documentation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building shared modules Initial Comment: [ report from http://bugs.debian.org/121759, submitted by Jochen Voss ] I tried to follow the description in /usr/share/doc/python2.1/html/ext/dnt-type- methods.html and the following manual sections in order to build a C extension module for Python 2.1. The mechanism does not work as advertised in the manual. To reproduce the problem try the following mkdir bugdir cd bugdir touch testx1module.c touch testx2module.c Now create a file named "Setup" with the following three lines in it: == Setup starts at next line ======================= *shared* testx1 testx1module.c testx2 testx2module.c -DFISCH=Barsch == Setup ends at previous line ===================== The third line will cause the problem later. I think it is valid syntax, because .../ext/module-defn-example.html states Several compiler options are supported: [...] -Dname=value Define a macro Now we try whether it works: type cp /usr/lib/python2.1/config/Makefile.pre.in . make -f Makefile.pre.in boot make For me this gives the output gcc -fPIC -g -O2 -Wall -Wstrict-prototypes - I/usr/include/python2.1 -I/usr/include/python2.1 - DHAVE_CONFIG_H -c ././testx1module.c - o ./testx1module.o gcc -shared ./testx1module.o - o ./testx1module.so The bug is the following: file "testx2module.so" is not created. And in fact "grep testx Makefile" emits SHAREDMODS= ./testx1module$(SO) testx2 testx2module.c -DFISCH=Barsch ./testx1module.o: $(srcdir)/./testx1module.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/./testx1module.c -o ./testx1module.o ./testx1module$(SO): ./testx1module.o; $(LDSHARED) ./testx1module.o -o ./testx1module$(SO) The second line looks suspicious. I can work around this by putting the defines in a variable, but I think this should be fixed nevertheless. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:06 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:21 Message: Logged In: YES user_id=21627 It's a documentation bug. The Setup.in method of building extensions is not supported anymore; please use distutils. If you can provide patches to bring Makefile.pre.in into a state so that it works for extensions again, such a patch would be incorporated (unless it breaks other things); we will not actively look for a solution. I assume that the specific section of the documentation you've been looking at is the same as http://www.python.org/doc/current/ext/building-on-unix.html (i.e. section 3, not section 2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:06:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:06:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-498823 ] Misc/Makefile.pre.in missing Message-ID: Bugs item #498823, was opened at 2002-01-02 20:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 Category: Demos and Tools Group: Python 2.2 Status: Open Resolution: Duplicate Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Misc/Makefile.pre.in missing Initial Comment: The Demo/extend directory contains demo files which depend on the presence of Misc/Makefile.pre.in, which is missing from the distribution. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:06 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-05 03:03 Message: Logged In: YES user_id=21627 In this modified form (embedding docs talk about Makefile.pre.in), this is a duplicate of #497695. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 21:49 Message: Logged In: YES user_id=6380 OK, reopened and assigned to Fred. Fred, feel free to close this if you already have a reminder for that. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-01-02 21:33 Message: Logged In: YES user_id=52572 In case it's not already known: there are also lots of docs in the extending/embedding section which depend on that file. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-02 20:59 Message: Logged In: YES user_id=6380 This was reported before, and has been fixed in CVS already. The Demo/extend directory is obsolete. Use the distutils package; docs are part of the standard 2.2 documentation bundle. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498823&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:07:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:07:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-497695 ] ext.doc uses deprecated(?) build proc. Message-ID: Bugs item #497695, was opened at 2001-12-29 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497695&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: ext.doc uses deprecated(?) build proc. Initial Comment: python2.2 and up: The ext docs (http://www.python.org/doc/current/ext/building-on- unix.html) describe the deprecated(?) build procedure. At least Makefile.pre.in isn't installed in /config. Should the documentation updated to a description how to build with distutils? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:07 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:24 Message: Logged In: YES user_id=21627 This is a bug, indeed, see my comments to 497697. Unless somebody volunteers to write a patch for Makefile.pre.in, I recommend to close 497697 as a duplicate of this report. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497695&group_id=5470 From noreply@sourceforge.net Tue Jan 8 22:08:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 14:08:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-497042 ] 2.2 is missing Misc/Makefile.pre.in? Message-ID: Bugs item #497042, was opened at 2001-12-27 06:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 candidate Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2 is missing Misc/Makefile.pre.in? Initial Comment: If I try to build Python-2.2/Demo/extend using make_shared, I get the message: % make_shared cp: cannot stat `../../Misc/Makefile.pre.in': No such file or directory make: Makefile.pre.in: No such file or directory make: *** No rule to make target `Makefile.pre.in'. Stop. make: *** No targets specified and no makefile found. Stop. Since we're trying to encourage using distutils for building extensions, I have updated the "extending demo". I've attached a tar file containing: setup.py # simple distutils script README # revised instructions test_xx.py # a simple test script for the 'xx' module ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:08 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 22:06 Message: Logged In: YES user_id=6380 If you find the distutil docs lacking, please submit a new bug report in the Documentation category. ---------------------------------------------------------------------- Comment By: Joseph VanAndel (vanandel) Date: 2001-12-27 09:29 Message: Logged In: YES user_id=6581 I understand that there is plenty of documentation for distutils, but are there (enough) other examples of extending, including defining objects and methods? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 09:02 Message: Logged In: YES user_id=6380 Thanks for noticing. The removal of Misc/Makefile.pre.in is intentional -- indeed we recommend using distutils and setup.py. But rather than using your setup.py, I decided that we don't need a demo -- there's plenty of doco for distutils. So I've just erased the Demo/extend directory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497042&group_id=5470 From noreply@sourceforge.net Wed Jan 9 00:05:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 16:05:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale Message-ID: Bugs item #497162, was opened at 2001-12-27 13:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Barry Warsaw (bwarsaw) Summary: test_email assumes Unix uses NTP scale Initial Comment: I got this test failure while building Python 2.2: test test_email failed -- Traceback (most recent call last): File "./Lib/test/test_email.py", line 935, in test_formatdate self.assertEqual(gdate, matchdate) File "/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' != 'Fri, 09 Nov 2001 17:33:52 -0000' This happens because the test assumes that the system clock is a count of non-leap seconds since the epoch. This is a common configuration, but it renders some clock values ambiguous, and complicates interval calculations. So my clock counts *all* seconds since the epoch. It would be nice if the test could handle both cases, by checking the broken-down values around a leap second, or by checking that the calculated string matches either of the two possibilities. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2002-01-08 16:05 Message: Logged In: YES user_id=412110 A different way of handling this, instead of the patch I gave, would be to set $TZ to something with known behavior. The TAI time zones are in right/; things like "US/Eastern" and "UTC" should work without the patch. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2002-01-01 00:46 Message: Logged In: YES user_id=412110 Are the Mac folks aware that the spaces impact everyone else, not just them? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-31 06:34 Message: Logged In: YES user_id=6380 Thanks for the patch. I'm assigning this to Barry, who wrote the test. Re spaces in filenames: I think the only filenames with spaces in them occur in the Mac subtree, and the Mac folks insist on having them... ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-30 23:18 Message: Logged In: YES user_id=412110 Sorry, I should have thought of providing a patch to begin with. On a separate note, some patches would not be so easy simply because of the filenames containing spaces. You might consider renaming those files. This bit me when I tried to patch the 2.1.1 sources up to 2.2 on a machine stuck behind a slow modem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:43 Message: Logged In: YES user_id=6380 If you want this fixed, please submit a patch. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2001-12-28 14:12 Message: Logged In: YES user_id=412110 Most software will trust localtime() and gmtime() to interpret the clock. It's only a problem here because you're testing (and thus doubting) the Python bindings to those functions, and rather than check it against some other use of the C functions, you check it against a precomputed string, thus doubting the C functions. C's localtime and gmtime give correct results on my system, because I'm using a time zone designed for a clock that counts all seconds. Don't doubt the C functions; they aren't what you're trying to test. I already explained the point of keeping the clock this way (the TAI scale): it simplifies interval calculations (the difference t1-t0 actually tells you how many seconds passed between those times), and it makes no clock values ambiguous. The NTP scale (counting only non-leap seconds) is a horrible bit of backward compatibility. By depending on it, you punish those with well-configured systems to reward those with badly-configured systems. I mentioned an easy fix, which is to compare the computed string to each of the values seen above, and to pass the test if it matches either of them. This will still fail for people who use even more exotic setups, but I don't know of any such. Is there anything wrong with this? I think the benefit easily outweighs the cost. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 13:54 Message: Logged In: YES user_id=6380 I think a lot of other software will fail too if you set your clock this way. What's the point? I don't want to argume too much about this, but I believe that this idea has been tried before and rejected. So I'm closing this as a won't fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470 From noreply@sourceforge.net Wed Jan 9 00:43:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 16:43:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Skip Montanaro (montanaro) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Bernard YUE (berniey) Date: 2002-01-08 16:43 Message: Logged In: YES user_id=419276 Hi Martin and Skip, Sorry for not explain myself clearly. What I mean is that &foobar should have been treated as '&foobar' literally (i.e. text), and &forbat; should be an entityref and &#forbar; as charref. Currently, sgmllib treated &foobar as entityref and &#foobar as charref and match it against entityref table and charref table. Ignores the entity when a match is not found. My suggested change should fix this problem. Run test.py (test.py and test.html attached) >./test.py Me! Me & You! Copyright@copy;abc Copyright©abc © © But we are expecting: Me&you! Me & You! Copyright@copy;abc Copyright©abc © © My suggested change will print the expected output. # test.html Testing Page

Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

# test.py #!/usr/bin/env python from htmllib import HTMLParser from formatter import AbstractFormatter, DumbWriter def test(): _formatter = AbstractFormatter( DumbWriter()) _parser = HTMLParser( _formatter) _f = open( './test.html') _parser.feed( _f.read()) _f.close() _parser.close() print '' if __name__ == '__main__': test() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Wed Jan 9 01:04:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 17:04:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Skip Montanaro (montanaro) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Bernard YUE (berniey) Date: 2002-01-08 17:04 Message: Logged In: YES user_id=419276 Hi again, I just run the test.html with w3c's HTML validator. &you does indeed treated as an invalid entityref in HTML 4.01. I've displays test.html under IE, Netscape and Konqueror and it all gave the result I've expected. I am not sure if sgmllib.py should stick with the standard or go with the general defacto interpretation. But I think it is more sensable to treat &you as text. Bernie ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 16:43 Message: Logged In: YES user_id=419276 Hi Martin and Skip, Sorry for not explain myself clearly. What I mean is that &foobar should have been treated as '&foobar' literally (i.e. text), and &forbat; should be an entityref and &#forbar; as charref. Currently, sgmllib treated &foobar as entityref and &#foobar as charref and match it against entityref table and charref table. Ignores the entity when a match is not found. My suggested change should fix this problem. Run test.py (test.py and test.html attached) >./test.py Me! Me & You! Copyright@copy;abc Copyright©abc © © But we are expecting: Me&you! Me & You! Copyright@copy;abc Copyright©abc © © My suggested change will print the expected output. # test.html Testing Page

Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

# test.py #!/usr/bin/env python from htmllib import HTMLParser from formatter import AbstractFormatter, DumbWriter def test(): _formatter = AbstractFormatter( DumbWriter()) _parser = HTMLParser( _formatter) _f = open( './test.html') _parser.feed( _f.read()) _f.close() _parser.close() print '' if __name__ == '__main__': test() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Wed Jan 9 03:20:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 19:20:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-501164 ] 2.2 on linux SEGV sometimes Message-ID: Bugs item #501164, was opened at 2002-01-08 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: MATSUI Tetsushi (tetsushi) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 on linux SEGV sometimes Initial Comment: I am using Python 2.2. The execution with pure python scripts suddenly stops after several hours or a few days. With the latest core I run gdb, it says: Program terminated with signal 11, Segmentation fault. and the head of bt is like this: #0 0x80afb1e in binary_op1 (v=0x8dc0f54, w=0x8c641bc, op_slot=4) at Objects/abstract.c:340 #1 0x80b2537 in PyNumber_Subtract (v=0x8dc0f54, w=0x8c641bc) at Objects/abstract.c:392 #2 0x8079f27 in eval_frame (f=0x820c1fc) at Python/ceval.c:988 #3 0x807cd50 in PyEval_EvalCodeEx (co=0x81cf608, globals=0x81d5214, locals=0x0, args=0x8202fc4, argcount=5, kws=0x8202fd8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2574 #4 0x807f41c in fast_function (func=0x81e4584, pp_stack=0xbfffe474, n=5, na=5, nk=0) at Python/ceval.c:3150 Thanks, tetsushi ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 From noreply@sourceforge.net Wed Jan 9 04:00:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 20:00:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-501164 ] 2.2 on linux SEGV sometimes Message-ID: Bugs item #501164, was opened at 2002-01-08 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: MATSUI Tetsushi (tetsushi) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 on linux SEGV sometimes Initial Comment: I am using Python 2.2. The execution with pure python scripts suddenly stops after several hours or a few days. With the latest core I run gdb, it says: Program terminated with signal 11, Segmentation fault. and the head of bt is like this: #0 0x80afb1e in binary_op1 (v=0x8dc0f54, w=0x8c641bc, op_slot=4) at Objects/abstract.c:340 #1 0x80b2537 in PyNumber_Subtract (v=0x8dc0f54, w=0x8c641bc) at Objects/abstract.c:392 #2 0x8079f27 in eval_frame (f=0x820c1fc) at Python/ceval.c:988 #3 0x807cd50 in PyEval_EvalCodeEx (co=0x81cf608, globals=0x81d5214, locals=0x0, args=0x8202fc4, argcount=5, kws=0x8202fd8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2574 #4 0x807f41c in fast_function (func=0x81e4584, pp_stack=0xbfffe474, n=5, na=5, nk=0) at Python/ceval.c:3150 Thanks, tetsushi ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:00 Message: Logged In: YES user_id=6380 Can you attach the script, any input data it needs, and instructions for running it? Otherwise there's no hope in debugging this. Also, how long is the stack? Could it be a stack overflow? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 From noreply@sourceforge.net Wed Jan 9 04:33:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 20:33:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Skip Montanaro (montanaro) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 20:33 Message: Logged In: YES user_id=44345 Bernie, I tried your patch. It looks good to me. I was a tad confused when I first read your bug report. I thought you were suggesting that "&foo" be interpreted as a charref/entityref. Instead you are tightening up the parser. That seems reasonable to me. Martin, what do you think? Skip ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 17:04 Message: Logged In: YES user_id=419276 Hi again, I just run the test.html with w3c's HTML validator. &you does indeed treated as an invalid entityref in HTML 4.01. I've displays test.html under IE, Netscape and Konqueror and it all gave the result I've expected. I am not sure if sgmllib.py should stick with the standard or go with the general defacto interpretation. But I think it is more sensable to treat &you as text. Bernie ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 16:43 Message: Logged In: YES user_id=419276 Hi Martin and Skip, Sorry for not explain myself clearly. What I mean is that &foobar should have been treated as '&foobar' literally (i.e. text), and &forbat; should be an entityref and &#forbar; as charref. Currently, sgmllib treated &foobar as entityref and &#foobar as charref and match it against entityref table and charref table. Ignores the entity when a match is not found. My suggested change should fix this problem. Run test.py (test.py and test.html attached) >./test.py Me! Me & You! Copyright@copy;abc Copyright©abc © © But we are expecting: Me&you! Me & You! Copyright@copy;abc Copyright©abc © © My suggested change will print the expected output. # test.html Testing Page

Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

# test.py #!/usr/bin/env python from htmllib import HTMLParser from formatter import AbstractFormatter, DumbWriter def test(): _formatter = AbstractFormatter( DumbWriter()) _parser = HTMLParser( _formatter) _f = open( './test.html') _parser.feed( _f.read()) _f.close() _parser.close() print '' if __name__ == '__main__': test() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Wed Jan 9 04:42:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 20:42:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:42 Message: Logged In: YES user_id=6380 I'm reassigning this to Fred. In 2.2, the new HTMLParser may or may not still have this problem. In 2.1.2, I think that "fixing" it would be too big a risk of breaking existing code, so I think it should not be fixed. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 20:33 Message: Logged In: YES user_id=44345 Bernie, I tried your patch. It looks good to me. I was a tad confused when I first read your bug report. I thought you were suggesting that "&foo" be interpreted as a charref/entityref. Instead you are tightening up the parser. That seems reasonable to me. Martin, what do you think? Skip ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 17:04 Message: Logged In: YES user_id=419276 Hi again, I just run the test.html with w3c's HTML validator. &you does indeed treated as an invalid entityref in HTML 4.01. I've displays test.html under IE, Netscape and Konqueror and it all gave the result I've expected. I am not sure if sgmllib.py should stick with the standard or go with the general defacto interpretation. But I think it is more sensable to treat &you as text. Bernie ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 16:43 Message: Logged In: YES user_id=419276 Hi Martin and Skip, Sorry for not explain myself clearly. What I mean is that &foobar should have been treated as '&foobar' literally (i.e. text), and &forbat; should be an entityref and &#forbar; as charref. Currently, sgmllib treated &foobar as entityref and &#foobar as charref and match it against entityref table and charref table. Ignores the entity when a match is not found. My suggested change should fix this problem. Run test.py (test.py and test.html attached) >./test.py Me! Me & You! Copyright@copy;abc Copyright©abc © © But we are expecting: Me&you! Me & You! Copyright@copy;abc Copyright©abc © © My suggested change will print the expected output. # test.html Testing Page

Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

# test.py #!/usr/bin/env python from htmllib import HTMLParser from formatter import AbstractFormatter, DumbWriter def test(): _formatter = AbstractFormatter( DumbWriter()) _parser = HTMLParser( _formatter) _f = open( './test.html') _parser.feed( _f.read()) _f.close() _parser.close() print '' if __name__ == '__main__': test() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Wed Jan 9 05:30:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 21:30:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 21:30 Message: Logged In: YES user_id=21627 I still recommend to reject this patch, it is plain wrong. Do we all agree that an HTML Document containing &you is ill-formed (all HTML versions)? If so, it is a matter of best-effort what to do with it. In SGML, it is well-formed to omit the semicolon from the entity name in a entity reference in certain cases, see http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi Therefore, omission of the semicolon does *not* mean that you don't have an entity reference, and sgmllib's processing of entity references is completely correct - it would be an error to treat &you as data. Therefore, your document is correct SGML. It just fails to be correct HTML, since the entity 'you' is not defined. If you want to process such a document in a specific way, I recommend to subclass HTMLParser, overriding unknown_entityref. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:42 Message: Logged In: YES user_id=6380 I'm reassigning this to Fred. In 2.2, the new HTMLParser may or may not still have this problem. In 2.1.2, I think that "fixing" it would be too big a risk of breaking existing code, so I think it should not be fixed. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 20:33 Message: Logged In: YES user_id=44345 Bernie, I tried your patch. It looks good to me. I was a tad confused when I first read your bug report. I thought you were suggesting that "&foo" be interpreted as a charref/entityref. Instead you are tightening up the parser. That seems reasonable to me. Martin, what do you think? Skip ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 17:04 Message: Logged In: YES user_id=419276 Hi again, I just run the test.html with w3c's HTML validator. &you does indeed treated as an invalid entityref in HTML 4.01. I've displays test.html under IE, Netscape and Konqueror and it all gave the result I've expected. I am not sure if sgmllib.py should stick with the standard or go with the general defacto interpretation. But I think it is more sensable to treat &you as text. Bernie ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 16:43 Message: Logged In: YES user_id=419276 Hi Martin and Skip, Sorry for not explain myself clearly. What I mean is that &foobar should have been treated as '&foobar' literally (i.e. text), and &forbat; should be an entityref and &#forbar; as charref. Currently, sgmllib treated &foobar as entityref and &#foobar as charref and match it against entityref table and charref table. Ignores the entity when a match is not found. My suggested change should fix this problem. Run test.py (test.py and test.html attached) >./test.py Me! Me & You! Copyright@copy;abc Copyright©abc © © But we are expecting: Me&you! Me & You! Copyright@copy;abc Copyright©abc © © My suggested change will print the expected output. # test.html Testing Page

Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

# test.py #!/usr/bin/env python from htmllib import HTMLParser from formatter import AbstractFormatter, DumbWriter def test(): _formatter = AbstractFormatter( DumbWriter()) _parser = HTMLParser( _formatter) _f = open( './test.html') _parser.feed( _f.read()) _f.close() _parser.close() print '' if __name__ == '__main__': test() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Wed Jan 9 05:36:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 21:36:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 7 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 21:36 Message: Logged In: YES user_id=21627 Including in Python.h should be possible. Of course, it may lead to breakage of existing extensions, since unistd.h may drag in (almost) arbitrary additional #defines and other global names, which could then confuse the extension code. One may argue that any such extension code would be already incorrect if it cannot stand inclusion of on Unix. So the risk should be very small. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 14:05 Message: Logged In: YES user_id=6380 Can't we #include in Python.h, if it exists? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:55 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in the extension modules. According to POSIX, an implementation (i.e. OS and C compiler) shall define _POSIX_THREADS in if threads are supported. Python 2.1 was always defining this, which was an error because it might have conflicted with the operating system settings. Python 2.2 only defines it if it finds a specific bug in the implementation: namely, if the system provides posix threads, but does not declare so in unistd.h. So the bug is in the extension modules: they must include to get _POSIX_THREADS. It is safe to include after including Python.h and checking HAVE_UNISTD_H. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Wed Jan 9 06:35:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 22:35:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar' Message-ID: Bugs item #500073, was opened at 2002-01-06 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Bernard YUE (berniey) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser fail to handle '&foobar' Initial Comment: HTMLParser did not distingish between &foobar; and &foobar. The later is still considered as a charref/entityref. Below is my posposed fix: File: sgmllib.py # SGMLParser.goahead() # line 162-176 # from elif rawdata[i] == '&': match = charref.match(rawdata, i) if match: name = match.group(1) self.handle_charref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue match = entityref.match(rawdata, i) if match: name = match.group(1) self.handle_entityref(name) i = match.end(0) if rawdata[i-1] != ';': i = i-1 continue # to elif rawdata[i] == '&' match = charref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an charref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_charref(name) i = match.end(0) continue match = entityref.match(rawdata, i) if match: if rawdata[match.end(0)-1] != ';': # not really an entitiyref self.handle_data(rawdata[i]) i = i+1 else: name = match.group(1) self.handle_entityref(name) i = match.end(0) continue ---------------------------------------------------------------------- >Comment By: Bernard YUE (berniey) Date: 2002-01-08 22:35 Message: Logged In: YES user_id=419276 Hi Guys, I felt embarrass as I confuss everybody here. Martin is nearly 100% right. Except that all &foo, &foo;, &#bar, &#bar; are all valid entity in HTML 4.01 as well if it was defined (I did not put enough test case in the old test.html to spot my mistake, when I ran it with the W3C Html validator, the new one should include all cases). Hence the existing sgmllib.py was correct. However, all the major browsers (IE, Natscape, Konqueror, Opera) choose to print the invalid HTML as plain text. Hence I think htmllib.py might as well follow the crowd as well. My suggestion is to added functions HTMLParser.unknown_charref() and and HTMLParser.unknown_entityref() as follows (files attached): # --- treat unknown entity as plain text def unknown_charref(self, ref): self.handle_data( '&#' + ref) def unknown_entityref(self, ref): self.handle_data( '&'+ ref) Sorry again for my previous incorrect patches. Bernie ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 21:30 Message: Logged In: YES user_id=21627 I still recommend to reject this patch, it is plain wrong. Do we all agree that an HTML Document containing &you is ill-formed (all HTML versions)? If so, it is a matter of best-effort what to do with it. In SGML, it is well-formed to omit the semicolon from the entity name in a entity reference in certain cases, see http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi Therefore, omission of the semicolon does *not* mean that you don't have an entity reference, and sgmllib's processing of entity references is completely correct - it would be an error to treat &you as data. Therefore, your document is correct SGML. It just fails to be correct HTML, since the entity 'you' is not defined. If you want to process such a document in a specific way, I recommend to subclass HTMLParser, overriding unknown_entityref. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:42 Message: Logged In: YES user_id=6380 I'm reassigning this to Fred. In 2.2, the new HTMLParser may or may not still have this problem. In 2.1.2, I think that "fixing" it would be too big a risk of breaking existing code, so I think it should not be fixed. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 20:33 Message: Logged In: YES user_id=44345 Bernie, I tried your patch. It looks good to me. I was a tad confused when I first read your bug report. I thought you were suggesting that "&foo" be interpreted as a charref/entityref. Instead you are tightening up the parser. That seems reasonable to me. Martin, what do you think? Skip ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 17:04 Message: Logged In: YES user_id=419276 Hi again, I just run the test.html with w3c's HTML validator. &you does indeed treated as an invalid entityref in HTML 4.01. I've displays test.html under IE, Netscape and Konqueror and it all gave the result I've expected. I am not sure if sgmllib.py should stick with the standard or go with the general defacto interpretation. But I think it is more sensable to treat &you as text. Bernie ---------------------------------------------------------------------- Comment By: Bernard YUE (berniey) Date: 2002-01-08 16:43 Message: Logged In: YES user_id=419276 Hi Martin and Skip, Sorry for not explain myself clearly. What I mean is that &foobar should have been treated as '&foobar' literally (i.e. text), and &forbat; should be an entityref and &#forbar; as charref. Currently, sgmllib treated &foobar as entityref and &#foobar as charref and match it against entityref table and charref table. Ignores the entity when a match is not found. My suggested change should fix this problem. Run test.py (test.py and test.html attached) >./test.py Me! Me & You! Copyright@copy;abc Copyright©abc © © But we are expecting: Me&you! Me & You! Copyright@copy;abc Copyright©abc © © My suggested change will print the expected output. # test.html Testing Page

Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

# test.py #!/usr/bin/env python from htmllib import HTMLParser from formatter import AbstractFormatter, DumbWriter def test(): _formatter = AbstractFormatter( DumbWriter()) _parser = HTMLParser( _formatter) _f = open( './test.html') _parser.feed( _f.read()) _f.close() _parser.close() print '' if __name__ == '__main__': test() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:02 Message: Logged In: YES user_id=21627 I fail to see the problem as well. Please attach an example document to this report. Without a detailed analysis of the problem in question, there is zero chance that any change like this is accepted. Here is my analysis from your report: It seems that you complain that sgmllib, when it sees an ill-formed document, behaves in a particular way, whereas you expect to behave it in a different way. Since the document is ill-formed anyways, any behaviour is as good as any other. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-01-08 13:03 Message: Logged In: YES user_id=44345 Bernie, I see nothing wrong in principal with recognizing " " when the user should have typed " ", but I wonder about the validity of " ". You mentioned it's still a charref or entityref. Is that documented somewhere or is it simply a practical approach to a common problem? Thanks, Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470 From noreply@sourceforge.net Wed Jan 9 07:00:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Jan 2002 23:00:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-501164 ] 2.2 on linux SEGV sometimes Message-ID: Bugs item #501164, was opened at 2002-01-08 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: MATSUI Tetsushi (tetsushi) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 on linux SEGV sometimes Initial Comment: I am using Python 2.2. The execution with pure python scripts suddenly stops after several hours or a few days. With the latest core I run gdb, it says: Program terminated with signal 11, Segmentation fault. and the head of bt is like this: #0 0x80afb1e in binary_op1 (v=0x8dc0f54, w=0x8c641bc, op_slot=4) at Objects/abstract.c:340 #1 0x80b2537 in PyNumber_Subtract (v=0x8dc0f54, w=0x8c641bc) at Objects/abstract.c:392 #2 0x8079f27 in eval_frame (f=0x820c1fc) at Python/ceval.c:988 #3 0x807cd50 in PyEval_EvalCodeEx (co=0x81cf608, globals=0x81d5214, locals=0x0, args=0x8202fc4, argcount=5, kws=0x8202fd8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2574 #4 0x807f41c in fast_function (func=0x81e4584, pp_stack=0xbfffe474, n=5, na=5, nk=0) at Python/ceval.c:3150 Thanks, tetsushi ---------------------------------------------------------------------- >Comment By: MATSUI Tetsushi (tetsushi) Date: 2002-01-08 23:00 Message: Logged In: YES user_id=421269 OK, I attach the main script. (Maybe the 1659-th line is the stopping point.) It consists of many factoring or primality testing functions and classes, and the stopping point I suspect is in the class MPQS. To run the algorithm MPQS(n).run() where n is about 30 decimal digit composite. The length of stack trace is 53. The last 3 are like this: #50 0x8053fcb in Py_Main (argc=5, argv=0xbffff644) at Modules/main.c:369 #51 0x8053a47 in main (argc=5, argv=0xbffff644) at Modules/python.c:10 #52 0x4004ca49 in Letext () Thanks, tetsushi. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:00 Message: Logged In: YES user_id=6380 Can you attach the script, any input data it needs, and instructions for running it? Otherwise there's no hope in debugging this. Also, how long is the stack? Could it be a stack overflow? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 From noreply@sourceforge.net Wed Jan 9 10:23:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 02:23:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 16:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Guido van Rossum (gvanrossum) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). _tryorder = os.environ["BROWSER"].split(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-09 02:23 Message: Logged In: NO But it is the other way around. Earlier you have: if os.environ.get("TERM") or os.environ.get("DISPLAY"): _tryorder = ("mozilla","netscape","kfm","grail","links","lynx","w3m") So _tryorder is _full_ of browsers. And then they are all registered, of course only if they are available, but disregarding $TERM and $DISPLAY. So mozilla _is_ registered, and _is_ in _tryorder, and _will_ be run. And, surprise, surprise, I run mostly on the virual console, and not in X. If it is supposed to be that way it's very strange for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=6380 I don't think this is a bug. The report doesn't explain what undesirable behavior follows, and it looks like some platforms need the registration. Note that the registry is independent from the try order -- the registry may contain browsers that are not in the try order, but they won't be used unless you add them to the try order yourself. Closing this as Invalid. BTW, please encourage your users to interact with SF directly rather than forwarding bugs from Debian here. It is too painful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Wed Jan 9 12:09:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 04:09:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-501264 ] Metaproperties Message-ID: Bugs item #501264, was opened at 2002-01-09 04:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501264&group_id=5470 Category: Type/class unification Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Metaproperties Initial Comment: When defining properties in a metaclass the setter function won't be called during the class object construction: --- class Meta(type): def getname(self): return self._name + "!" def setname(self, name): self._name = name name = property(getname, setname) class Element(object): __metaclass__ = Meta name = "test" --- print Element.name results in a "AttributeError: type object 'Element' has no attribute '_name'" but there is a 'name' attribute in Element.__dict__ http://www.python.org/2.2/descrintro.html clearly describes this behaviour, but is it possible to changes this to make metaproperties work (without having to fiddle with the dict in Meta.__new__)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501264&group_id=5470 From noreply@sourceforge.net Wed Jan 9 13:29:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 05:29:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-501288 ] problems with divising Message-ID: Bugs item #501288, was opened at 2002-01-09 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501288&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Zsolt Cserna (csernazs) Assigned to: Nobody/Anonymous (nobody) Summary: problems with divising Initial Comment: I have problems with divising (int/float) in python 2.1.1. For example, if I try divide two numbers (45/100.0), the result of this will be not correct. >>> 45/100.0 0.45000000000000001 Python 2.1.1+ (#1, Jan 8 2002, 00:37:12) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 With python 1.5 it works correctly. Thanks for help. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501288&group_id=5470 From noreply@sourceforge.net Wed Jan 9 13:32:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 05:32:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 7 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- >Comment By: Konrad Hinsen (hinsen) Date: 2002-01-09 05:32 Message: Logged In: YES user_id=11850 Including in Python.h sounds like a good solution to me. But first of all, please change the comment for _POSIX_THREADS in pyconfig.h. I am probably not the only one to use the Python sources for documentation purposes - contrary to POSIX documents, which I have never seen. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 21:36 Message: Logged In: YES user_id=21627 Including in Python.h should be possible. Of course, it may lead to breakage of existing extensions, since unistd.h may drag in (almost) arbitrary additional #defines and other global names, which could then confuse the extension code. One may argue that any such extension code would be already incorrect if it cannot stand inclusion of on Unix. So the risk should be very small. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 14:05 Message: Logged In: YES user_id=6380 Can't we #include in Python.h, if it exists? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:55 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in the extension modules. According to POSIX, an implementation (i.e. OS and C compiler) shall define _POSIX_THREADS in if threads are supported. Python 2.1 was always defining this, which was an error because it might have conflicted with the operating system settings. Python 2.2 only defines it if it finds a specific bug in the implementation: namely, if the system provides posix threads, but does not declare so in unistd.h. So the bug is in the extension modules: they must include to get _POSIX_THREADS. It is safe to include after including Python.h and checking HAVE_UNISTD_H. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Wed Jan 9 13:57:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 05:57:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 16:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library Group: Not a Bug >Status: Open Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). _tryorder = os.environ["BROWSER"].split(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-09 05:57 Message: Logged In: YES user_id=6380 If your real complaint is that you are not running under X yet it tries to start Mozilla, please say so. If that's the case, we have to figure out where the bug is. reopening and assigning to Fred Drake -- I don't follow the login in the module and the use of the _tryorder and _browsers variable is not documented very well. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-09 02:23 Message: Logged In: NO But it is the other way around. Earlier you have: if os.environ.get("TERM") or os.environ.get("DISPLAY"): _tryorder = ("mozilla","netscape","kfm","grail","links","lynx","w3m") So _tryorder is _full_ of browsers. And then they are all registered, of course only if they are available, but disregarding $TERM and $DISPLAY. So mozilla _is_ registered, and _is_ in _tryorder, and _will_ be run. And, surprise, surprise, I run mostly on the virual console, and not in X. If it is supposed to be that way it's very strange for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=6380 I don't think this is a bug. The report doesn't explain what undesirable behavior follows, and it looks like some platforms need the registration. Note that the registry is independent from the try order -- the registry may contain browsers that are not in the try order, but they won't be used unless you add them to the try order yourself. Closing this as Invalid. BTW, please encourage your users to interact with SF directly rather than forwarding bugs from Debian here. It is too painful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Wed Jan 9 14:03:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 06:03:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-501264 ] Metaproperties Message-ID: Bugs item #501264, was opened at 2002-01-09 04:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501264&group_id=5470 Category: Type/class unification Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Metaproperties Initial Comment: When defining properties in a metaclass the setter function won't be called during the class object construction: --- class Meta(type): def getname(self): return self._name + "!" def setname(self, name): self._name = name name = property(getname, setname) class Element(object): __metaclass__ = Meta name = "test" --- print Element.name results in a "AttributeError: type object 'Element' has no attribute '_name'" but there is a 'name' attribute in Element.__dict__ http://www.python.org/2.2/descrintro.html clearly describes this behaviour, but is it possible to changes this to make metaproperties work (without having to fiddle with the dict in Meta.__new__)? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-09 06:03 Message: Logged In: YES user_id=6380 I'm afraid this is how it's gonna be -- the metaclass doesn't get control until after the body of the class statement is executed. That's not easy to change. Closing this as Won't Fix. Feel free to email me directly about this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501264&group_id=5470 From noreply@sourceforge.net Wed Jan 9 14:28:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 06:28:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 16:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library >Group: None Status: Open Resolution: Invalid >Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). _tryorder = os.environ["BROWSER"].split(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 06:28 Message: Logged In: YES user_id=3066 Sounds painful, but I can't look at it right now (though I don't think it will be hard to fix). I've bumped the priority up and set the tracker fields to reasonable values for this report. I'll need to be careful about testing this with & without $BROWSER both on a console and under X. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-09 05:57 Message: Logged In: YES user_id=6380 If your real complaint is that you are not running under X yet it tries to start Mozilla, please say so. If that's the case, we have to figure out where the bug is. reopening and assigning to Fred Drake -- I don't follow the login in the module and the use of the _tryorder and _browsers variable is not documented very well. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-09 02:23 Message: Logged In: NO But it is the other way around. Earlier you have: if os.environ.get("TERM") or os.environ.get("DISPLAY"): _tryorder = ("mozilla","netscape","kfm","grail","links","lynx","w3m") So _tryorder is _full_ of browsers. And then they are all registered, of course only if they are available, but disregarding $TERM and $DISPLAY. So mozilla _is_ registered, and _is_ in _tryorder, and _will_ be run. And, surprise, surprise, I run mostly on the virual console, and not in X. If it is supposed to be that way it's very strange for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=6380 I don't think this is a bug. The report doesn't explain what undesirable behavior follows, and it looks like some platforms need the registration. Note that the registry is independent from the try order -- the registry may contain browsers that are not in the try order, but they won't be used unless you add them to the try order yourself. Closing this as Invalid. BTW, please encourage your users to interact with SF directly rather than forwarding bugs from Debian here. It is too painful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Wed Jan 9 14:37:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 06:37:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 16:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Invalid Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.py: selection of browser Initial Comment: [please CC 121737@bugs.debian.org on replies; complete report can be found at http://bugs.debian.org/121737 ] webbrowser.py tries hard to select correct browsers and then wastes it The culprit is the last loop, registering everything possible. I'm not sure, but wasn't it supposed to run only in the environ["BROWSER"] case like this?: -----diff start----- --- /usr/lib/python2.1/webbrowser.py Sun Nov 11 18:23:54 2001 +++ /tmp/webbrowser.py Thu Nov 29 17:40:46 2001 @@ -305,11 +305,10 @@ # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). _tryorder = os.environ["BROWSER"].split(":") - -for cmd in _tryorder: - if not _browsers.has_key(cmd.lower()): - if _iscommand(cmd.lower()): - register(cmd.lower(), None, GenericBrowser ("%s %%s" % cmd.lower())) + for cmd in _tryorder: + if not _browsers.has_key(cmd.lower()): + if _iscommand(cmd.lower()): + register(cmd.lower(), None, GenericBrowser("%s %%s" % cmd.lower())) _tryorder = filter(lambda x: _browsers.has_key(x.lower ()) or x.find("%s") > -1, _tryorder) -----diff end----- ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 06:37 Message: Logged In: YES user_id=3066 I'll make a note here so I don't forget: I should add galeon and skipstone to the list of known browsers. (Both are based on the Mozilla engine.) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 06:28 Message: Logged In: YES user_id=3066 Sounds painful, but I can't look at it right now (though I don't think it will be hard to fix). I've bumped the priority up and set the tracker fields to reasonable values for this report. I'll need to be careful about testing this with & without $BROWSER both on a console and under X. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-09 05:57 Message: Logged In: YES user_id=6380 If your real complaint is that you are not running under X yet it tries to start Mozilla, please say so. If that's the case, we have to figure out where the bug is. reopening and assigning to Fred Drake -- I don't follow the login in the module and the use of the _tryorder and _browsers variable is not documented very well. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-09 02:23 Message: Logged In: NO But it is the other way around. Earlier you have: if os.environ.get("TERM") or os.environ.get("DISPLAY"): _tryorder = ("mozilla","netscape","kfm","grail","links","lynx","w3m") So _tryorder is _full_ of browsers. And then they are all registered, of course only if they are available, but disregarding $TERM and $DISPLAY. So mozilla _is_ registered, and _is_ in _tryorder, and _will_ be run. And, surprise, surprise, I run mostly on the virual console, and not in X. If it is supposed to be that way it's very strange for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:19 Message: Logged In: YES user_id=6380 I don't think this is a bug. The report doesn't explain what undesirable behavior follows, and it looks like some platforms need the registration. Note that the registry is independent from the try order -- the registry may contain browsers that are not in the try order, but they won't be used unless you add them to the try order yourself. Closing this as Invalid. BTW, please encourage your users to interact with SF directly rather than forwarding bugs from Debian here. It is too painful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Wed Jan 9 18:40:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 10:40:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-501288 ] problems with divising Message-ID: Bugs item #501288, was opened at 2002-01-09 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501288&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Deleted >Resolution: Invalid Priority: 5 Submitted By: Zsolt Cserna (csernazs) >Assigned to: Tim Peters (tim_one) Summary: problems with divising Initial Comment: I have problems with divising (int/float) in python 2.1.1. For example, if I try divide two numbers (45/100.0), the result of this will be not correct. >>> 45/100.0 0.45000000000000001 Python 2.1.1+ (#1, Jan 8 2002, 00:37:12) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 With python 1.5 it works correctly. Thanks for help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-09 10:40 Message: Logged In: YES user_id=31435 This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for more information: http://python.sourceforge.net/devel-docs/tut/node14.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501288&group_id=5470 From noreply@sourceforge.net Wed Jan 9 18:42:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 10:42:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-501288 ] problems with divising Message-ID: Bugs item #501288, was opened at 2002-01-09 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501288&group_id=5470 Category: Python Interpreter Core Group: Not a Bug >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Zsolt Cserna (csernazs) Assigned to: Tim Peters (tim_one) Summary: problems with divising Initial Comment: I have problems with divising (int/float) in python 2.1.1. For example, if I try divide two numbers (45/100.0), the result of this will be not correct. >>> 45/100.0 0.45000000000000001 Python 2.1.1+ (#1, Jan 8 2002, 00:37:12) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 With python 1.5 it works correctly. Thanks for help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-09 10:40 Message: Logged In: YES user_id=31435 This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for more information: http://python.sourceforge.net/devel-docs/tut/node14.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501288&group_id=5470 From noreply@sourceforge.net Thu Jan 10 02:20:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 18:20:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-501591 ] dir() doc is old Message-ID: Bugs item #501591, was opened at 2002-01-09 18:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501591&group_id=5470 Category: Documentation Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: dir() doc is old Initial Comment: "Brian Quinlan" reports on c.l.p that dir() is incorrect in the library reference. The current doc string seems to be more accurate: Return an alphabetized list of names comprising (some of) the attributes of the given object, and of attributes reachable from it: No argument: the names in the current scope. Module object: the module attributes. Type or class object: its attributes, and recursively the attributes of its bases. Otherwise: its attributes, its class's attributes, and recursively the attributes of its class's base classes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501591&group_id=5470 From noreply@sourceforge.net Thu Jan 10 04:01:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 20:01:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError Message-ID: Bugs item #501622, was opened at 2002-01-09 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Bolen (db3l) Assigned to: Nobody/Anonymous (nobody) Summary: compile() 'exec' mode SyntaxError Initial Comment: If you have a module that you wish to compile using the builtin compile() function (in 'exec' mode), it will fail with a SyntaxError if that module does not have a newline as its final token. The same module can be executed directly by the interpreter, or imported by another module, and Python can properly compile and save a pyc for the module. I believe the difference is rooted in the fact that the tokenizer (tokenizer.c, in tok_nextc()) will "fake" a newline at the end of a file if it doesn't find one, but it will not do so when tokenizing a string buffer. What I'm not certain of is whether faking such a token for strings as well won't break something else (such as when parsing a string for an expression rather than a full module). But without such a change, you have a state where a module that works (and compiles) in other circumstances cannot be read into memory and compiled with the compile() builtin. This came up while tracking down a problem with failures using Gordan McMillan's Installer package which compiles modules using compile() before including them in the archive. I believe this is true for all releases since at least 1.5.2. -- David ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470 From noreply@sourceforge.net Thu Jan 10 04:09:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Jan 2002 20:09:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-501623 ] traceback problem Message-ID: Bugs item #501623, was opened at 2002-01-09 20:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501623&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: traceback problem Initial Comment: This showed up on the Scons-devel list a few days ago, posted by Anthony Roach (aroach@electriceyeball.com): On Tue, Jan 08, 2002 at 09:11:56AM -0600, Charles Crain wrote: > Python 2.2 is out now, so I downloaded it and ran the test suite. > Everything passed except for errors.py, because it seems they changed the > syntax of the traceback a tad. I saw this too, and as far as I can tell it's a bug in Python 2.2. Basically syntax errors no longer tell you what the file is where the syntax error is, and where the filename used to be it just says . Someone should file a bug report to Python about this... -- Verified: Administrator@MOREPIE e:/temp $ cat > c:/temp/foo.py def foo bar: pass Administrator@MOREPIE e:/temp $ python c:/temp/foo.py File "", line 1 def foo bar: ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501623&group_id=5470 From noreply@sourceforge.net Thu Jan 10 10:39:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 02:39:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-501716 ] "es#" parser marker leaks memory Message-ID: Bugs item #501716, was opened at 2002-01-10 02:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501716&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: "es#" parser marker leaks memory Initial Comment: ... if subsequent parsing fails, a buffer which was possibly allocated by "es#" is not freed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501716&group_id=5470 From noreply@sourceforge.net Thu Jan 10 11:17:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 03:17:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 03:17 Message: Logged In: YES user_id=29957 This is almost certainly fixed by the compiler fixes - I can't get it to crash now. Closing. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 19:09 Message: Logged In: YES user_id=29957 It seems very likely that the recent compiler stack calculation fixes are responsible for this - I plan to look into this when I get back into work on the 3rd. ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-16 16:31 Message: Logged In: YES user_id=358486 No, I haven't tried the ceval.c patch. Do know of any documentation regarding this bug and the bug fix? I'm just curious before applying this patch. There also is an update from the folks at ZC. They located a source of trouble with respect to python 2.1 and the restricted dtml engine. See the zope-dev mailing list for futher details. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-14 02:46 Message: Logged In: YES user_id=21627 natsukashi, have you applied 2.277 of ceval.c? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-13 16:41 Message: Logged In: YES user_id=358486 Here is an excerpt from one debugging session ... > (gdb) info threads > 17 Thread 10 0xef5b9810 in _lwp_sema_wait () > 16 Thread 9 0xef647cac in _swtch () > 15 Thread 8 0xef5b9810 in _lwp_sema_wait () > 14 Thread 7 (LWP 5) 0xcaeb50 in ?? () > 13 Thread 6 0xef647cac in _swtch () > 12 Thread 5 0xef5b9810 in _lwp_sema_wait () > 11 Thread 4 0xef647cac in _swtch () > 10 Thread 3 0xef647cac in _swtch () > 9 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () > 8 Thread 1 (LWP 6) 0xef5b7488 in _poll () > 7 LWP 8 0xef5b6a24 in door_restart () > 6 LWP 6 0xef5b7488 in _poll () > 5 LWP 5 0xcaeb50 in ?? () > 4 LWP 4 0xef5b9810 in _lwp_sema_wait () > 3 LWP 3 0xef5b9810 in _lwp_sema_wait () > 2 LWP 2 0xef5b9958 in _signotifywait () > * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () > > (gdb) thread 14 > [Switching to Thread 7 (LWP 5)] > #0 0xcaeb50 in ?? () > > (gdb) where > #0 0xcaeb50 in ?? () > #1 0x516bc in collect (young=0x13dec8, old=0x13ded4) > at ./Modules/gcmodule.c:379 > #2 0x51984 in collect_generations () at ./Modules/gcmodule.c:484 > #3 0x519fc in _PyGC_Insert (op=0xecf7d4) at ./Modules/gcmodule.c:507 > #4 0x664ec in PyMethod_New (func=0x3f796c, self=0x11c0d44, > class=0x3c7e5c) > at Objects/classobject.c:1834 > #5 0x63850 in instance_getattr2 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:642 > #6 0x63750 in instance_getattr1 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:608 > #7 0x63898 in instance_getattr (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:656 > #8 0x78330 in PyObject_GetAttr (v=0x11c0d44, name=0x3d5378) > at Objects/object.c:1052 > #9 0x895ec in builtin_hasattr (self=0x0, args=0x12ed944) > at Python/bltinmodule.c:886 > #10 0x35a44 in call_cfunction (func=0x1609b0, arg=0x12ed944, kw=0x0) > at Python/ceval.c:2854 Unfortunately, I do not have any specific information at the moment. There is also portions of a discussion that can be viewed with the following url: http://lists.zope.org/pipermail/zope-dev/2001-December/014541.html Look for messages having the same subject. Basically, we are running python 2.1.1 and zope 2.4.3 on the solaris platform. We have 3 servers each having the same installed software except one server is solaris 5.6 and the other two are solaris 5.7. The zope process running on the solaris 5.6 machine is restarting at least a couple times a day due to a SIGSEGV or SIGILL signal. I can generate a core file using the truss command. The problem appears to be related to garbage collection. Unfortunately, this behavior only occurs on our production site and depends on the site load -- higher system load, more frequent restarts. We are not facing any restart troubles on the solaris 5.7 machines or on our linux and solaris development machines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Thu Jan 10 12:46:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 04:46:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads Group: Python 2.1.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Simo Salminen (frangen) Assigned to: Guido van Rossum (gvanrossum) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 04:46 Message: Logged In: YES user_id=29957 checked in to 2.1.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:07 Message: Logged In: YES user_id=6380 I've checked in a fix that simply ignores the error in this case: threading.py rev. 1.20. This is a 2.1.2 and 2.2.1 bugfix candidate! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 06:35 Message: Logged In: YES user_id=6380 Good. I saw the same thing in a program, also one using daemon threads. The daemon threads make this thing understandable. I'll think of a fix. ---------------------------------------------------------------------- Comment By: Simo Salminen (frangen) Date: 2001-12-27 14:21 Message: Logged In: YES user_id=291461 Yes, program is running a mainthread and two daemon threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 11:51 Message: Logged In: YES user_id=6380 Hm, this looks like it could happen when the treading module is deleted while there are still threads running. But that can only happen with daemon threads. Does your program have daemon threads? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Thu Jan 10 12:49:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 04:49:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-497111 ] active_limbo_lock error at program exit Message-ID: Bugs item #497111, was opened at 2001-12-27 11:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 Category: Threads Group: Python 2.1.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Simo Salminen (frangen) Assigned to: Guido van Rossum (gvanrossum) Summary: active_limbo_lock error at program exit Initial Comment: I'm running my threaded application, and now and then I get following error at exit. I'm using python 2.2 final, but I have had the same error with python 2.1. Unfortunately I cannot reproduce it. This bug has only occured when I've run the program under win2ksp2, tried to produce it under linux but without luck. My program is pure python application. I guess saving reference to _active_limbo_lock at Thread-class could solve the problem.. Traceback (most recent call last): File "C:\utils\PYTHON22\lib\threading.py", line 424, in __bootstrap self.__delete() File "C:\utils\PYTHON22\lib\threading.py", line 433, in __delete _active_limbo_lock.acquire() AttributeError: 'NoneType' object has no attribute 'acquire' ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 04:49 Message: Logged In: YES user_id=29957 checked in to 2.1.2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 04:46 Message: Logged In: YES user_id=29957 checked in to 2.1.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 14:07 Message: Logged In: YES user_id=6380 I've checked in a fix that simply ignores the error in this case: threading.py rev. 1.20. This is a 2.1.2 and 2.2.1 bugfix candidate! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 06:35 Message: Logged In: YES user_id=6380 Good. I saw the same thing in a program, also one using daemon threads. The daemon threads make this thing understandable. I'll think of a fix. ---------------------------------------------------------------------- Comment By: Simo Salminen (frangen) Date: 2001-12-27 14:21 Message: Logged In: YES user_id=291461 Yes, program is running a mainthread and two daemon threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 11:51 Message: Logged In: YES user_id=6380 Hm, this looks like it could happen when the treading module is deleted while there are still threads running. But that can only happen with daemon threads. Does your program have daemon threads? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497111&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:01:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:01:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:21:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:21:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-501795 ] pickle/cPickle EOL incompatibility Message-ID: Bugs item #501795, was opened at 2002-01-10 06:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501795&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: James Weatherall (sleeper) Assigned to: Nobody/Anonymous (nobody) Summary: pickle/cPickle EOL incompatibility Initial Comment: There seems to be a problem loading pickled data written under Windows (EOL = \r\n) from within Linux (EOL = \n). The problem manifests as being unable to import the required module. Reading Linux pickle data under Windows works fine. e.g. a pickle file containing objects from module Foo will fail to import Foo, because it *actually* tries to import "Foo\r", and obviously can't. (Seems unlikely that noone else has noticed this, so perhaps I'm just being spectacularly dumb.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501795&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:26:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:26:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-01-10 06:26 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:27:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:27:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-01-10 06:27 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:26 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:28:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:28:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-01-10 06:28 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:27 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:26 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:37:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:37:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-471942 ] python2.1.1 SEGV in GC on Solaris 2.7 Message-ID: Bugs item #471942, was opened at 2001-10-16 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: python2.1.1 SEGV in GC on Solaris 2.7 Initial Comment: I've got a Zope installation where python2.1.1 is segfaulting on Solaris2.7 - it's running a largish ZEO server. The tail of the gdb output is: #128 0x26164 in PyEval_CallObjectWithKeywords () #129 0x264c0 in PyEval_CallObjectWithKeywords () #130 0x26140 in PyEval_CallObjectWithKeywords () #131 0x25fc0 in PyEval_CallObjectWithKeywords () #132 0x517bc in PyInstance_New () #133 0x261a4 in PyEval_CallObjectWithKeywords () #134 0x25fc0 in PyEval_CallObjectWithKeywords () #135 0x42c90 in initgc () It's built with $ gcc -v Reading specs from /opt/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) which is a bit old. I'm going to rebuild with gcc3.0 and also try turning off the GC. Unfortunately I can't get this to happen on a smaller test system - it's only under load that it plows into the ground. I'll also leave symbols in this time... :/ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-10 06:37 Message: Logged In: YES user_id=6380 Yay! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 03:17 Message: Logged In: YES user_id=29957 This is almost certainly fixed by the compiler fixes - I can't get it to crash now. Closing. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-22 19:09 Message: Logged In: YES user_id=29957 It seems very likely that the recent compiler stack calculation fixes are responsible for this - I plan to look into this when I get back into work on the 3rd. ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-16 16:31 Message: Logged In: YES user_id=358486 No, I haven't tried the ceval.c patch. Do know of any documentation regarding this bug and the bug fix? I'm just curious before applying this patch. There also is an update from the folks at ZC. They located a source of trouble with respect to python 2.1 and the restricted dtml engine. See the zope-dev mailing list for futher details. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-14 02:46 Message: Logged In: YES user_id=21627 natsukashi, have you applied 2.277 of ceval.c? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-13 16:41 Message: Logged In: YES user_id=358486 Here is an excerpt from one debugging session ... > (gdb) info threads > 17 Thread 10 0xef5b9810 in _lwp_sema_wait () > 16 Thread 9 0xef647cac in _swtch () > 15 Thread 8 0xef5b9810 in _lwp_sema_wait () > 14 Thread 7 (LWP 5) 0xcaeb50 in ?? () > 13 Thread 6 0xef647cac in _swtch () > 12 Thread 5 0xef5b9810 in _lwp_sema_wait () > 11 Thread 4 0xef647cac in _swtch () > 10 Thread 3 0xef647cac in _swtch () > 9 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () > 8 Thread 1 (LWP 6) 0xef5b7488 in _poll () > 7 LWP 8 0xef5b6a24 in door_restart () > 6 LWP 6 0xef5b7488 in _poll () > 5 LWP 5 0xcaeb50 in ?? () > 4 LWP 4 0xef5b9810 in _lwp_sema_wait () > 3 LWP 3 0xef5b9810 in _lwp_sema_wait () > 2 LWP 2 0xef5b9958 in _signotifywait () > * 1 LWP 1 0xef5b9810 in _lwp_sema_wait () > > (gdb) thread 14 > [Switching to Thread 7 (LWP 5)] > #0 0xcaeb50 in ?? () > > (gdb) where > #0 0xcaeb50 in ?? () > #1 0x516bc in collect (young=0x13dec8, old=0x13ded4) > at ./Modules/gcmodule.c:379 > #2 0x51984 in collect_generations () at ./Modules/gcmodule.c:484 > #3 0x519fc in _PyGC_Insert (op=0xecf7d4) at ./Modules/gcmodule.c:507 > #4 0x664ec in PyMethod_New (func=0x3f796c, self=0x11c0d44, > class=0x3c7e5c) > at Objects/classobject.c:1834 > #5 0x63850 in instance_getattr2 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:642 > #6 0x63750 in instance_getattr1 (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:608 > #7 0x63898 in instance_getattr (inst=0x11c0d44, name=0x3d5378) > at Objects/classobject.c:656 > #8 0x78330 in PyObject_GetAttr (v=0x11c0d44, name=0x3d5378) > at Objects/object.c:1052 > #9 0x895ec in builtin_hasattr (self=0x0, args=0x12ed944) > at Python/bltinmodule.c:886 > #10 0x35a44 in call_cfunction (func=0x1609b0, arg=0x12ed944, kw=0x0) > at Python/ceval.c:2854 Unfortunately, I do not have any specific information at the moment. There is also portions of a discussion that can be viewed with the following url: http://lists.zope.org/pipermail/zope-dev/2001-December/014541.html Look for messages having the same subject. Basically, we are running python 2.1.1 and zope 2.4.3 on the solaris platform. We have 3 servers each having the same installed software except one server is solaris 5.6 and the other two are solaris 5.7. The zope process running on the solaris 5.6 machine is restarting at least a couple times a day due to a SIGSEGV or SIGILL signal. I can generate a core file using the truss command. The problem appears to be related to garbage collection. Unfortunately, this behavior only occurs on our production site and depends on the site load -- higher system load, more frequent restarts. We are not facing any restart troubles on the solaris 5.7 machines or on our linux and solaris development machines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 12:12 Message: Logged In: YES user_id=31435 Just noting that the function names reported in the traceback in the original writeup are bogus: PyEval_CallObjectWithKeywords() doesn't call itself. Looks like gdb doesn't have enough info to report the true function name, so picks a function it does know about at an earlier address (or something ). I'm told this doesn't happen on Linux, but don't grasp why it might on Solaris. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-13 07:45 Message: Logged In: YES user_id=21627 What do you mean with "the same trouble"? Merely that Python crashes, or do you have some more specific information to contribute? ---------------------------------------------------------------------- Comment By: Joseph Wayne Norton (natsukashi) Date: 2001-12-11 18:37 Message: Logged In: YES user_id=358486 Do you have any updates on this issue? I'm facing the same trouble on the following solaris platform: SunOS i04sv2008 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-80 regards, - j ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-12-04 23:38 Message: Logged In: YES user_id=29957 Nah, this is a separate one to the frame bug. I'm still seeing it on a regular regular basis, but haven't narrowed it done to what's causing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-12-04 08:48 Message: Logged In: YES user_id=31392 This was the bug that was tracked down to a problem in try/except/finally, wasn't it? If this is fixed, can you close the bug report? If not, can you provide an udpate on its current status? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-07 14:13 Message: Logged In: YES user_id=21627 Any news on this report: did the problem disappear after backporting changes? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 04:32 Message: Logged In: YES user_id=21627 Looking at the changes since 2.1.1, I can see one bugfix that might explain strange behaviour, namely ceval.c 2.277. If you want to try it out, you can get the change here http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/ceval.c.diff?r1=2.276&r2=2.277 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:59 Message: Logged In: YES user_id=29957 What's the appropriate way to ask this? drop a line to python-dev? purify's showing a UMR in strop_expandtabs (from memory - don't have it on screen right now) when python starts up. Yeah, the realloc bug concerns me - I have to wonder if something's a little bit/lot screwy. I just don't know where. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:46 Message: Logged In: YES user_id=21627 This is something to ask the pythonlabs folks; I believe Python has been purified once in a while - perhaps even with Zope extensions. I'd still suspect a bug in the Zope extensions instead of a Python bug, though: if malloc crashes, chances are high that somebody was overwriting free memory. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-18 03:31 Message: Logged In: YES user_id=29957 It's not a GC object. I'm positive all the extension objects are correct - I just recompiled, without the 1.5/2.0 headers around. It's a different pointer each time round, unfortunately. It also takes anything from 5 minutes to 2 hours to reproduce. I've got about 4 copies of it running now, and I've got a bunch of different core files. I've grabbed purify and an eval license, and I'm feeding it the binary. The printf approach is probably not going to work - these are busy busy Zope servers. Instead, my plan, assuming that purify doesn't immediately spot a problem, is to change the code so that if it gets a dud GC object, it will just bust it out of the tree and let it leak, and print a message saying so. Then I can quit the program, and purify will tell me 'hey, you leaked!' and also tell me where it was allocated. More concerning, about half the segfaults are not from the GC at all, but from realloc in PyFrame_New (line 161 of frameobject). These are the only two I'm getting - it's split 50-50 amongst the 10 coredumps I have now. I'm not sure whether to open a seperate bug for this. Has python2.1.1 been purified? With Zope and zope's extensions? Wow - it's amazing how this SF bug thing is so painful for conversations :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-18 03:11 Message: Logged In: YES user_id=21627 There are two options: a) the object isn't really a GC object, i.e. has no GC header. In gdb, you can try to cast gc to PyObject*, then see if the resulting pointer has a better ob_type (this is unlikely, though, since the logic entering the object was already using fromgc/togc) b) somebody has cleared the ob_type field. Can you guarantee that all extension modules have been compiled with the 2.1.1 header files? Is the problem repeatable in the sense that gc will have the same pointer value on each crash? If so, it is relatively easy to track down: just set a gdb change watchpoint on the address on the ob_type field of that address (note that setting watchpoints is not possible until there is really mapped memory on that address). If you can't analyse it through change breakpoints, I recommend to annotate the interpreter in the following way: in pyobject_init, put a printf that prints the address and the tp_name of the type. In subtract_refs, if the ob_type slot is null, print the address of the object and abort. Then analyse the log to see whether a object really has been allocated on that address, and what its type was (make sure you consider the possibility that address are off by the delta that FROM_GC adds). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 21:58 Message: Logged In: YES user_id=29957 Ok, I have an intact core file, and a matching binary, no optimisations, nothing. This crash is showing the crash at line 166 of gcmodule.c traverse = PyObject_FROM_GC(gc)->ob_type->tp_traverse; PyObject_FROM_GC(gc)->ob_type in this case is $24 = {ob_refcnt = 1, ob_type = 0x0} To check my logic, I checked gc_next and gc_prev using the same GDB magic, and they correctly show up as a tuple and an instance method. Some fiddling around seems to rule out stack space as the problem, as well. We're going to try and see if purify helps here, but the problem looks to be a junk object - I have no idea how to track this down further. Help? Would taking the horrible horrible hack of removing the object from the gc linked list if ob_type is null help? Well, it'd stop the crashes, anyway. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-17 13:44 Message: Logged In: YES user_id=21627 It would be interesting what the value of "gc" is at the time of the crash. It looks like you got an object that claims to support GC but has a null tp_traverse. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2001-10-17 06:08 Message: Logged In: YES user_id=29957 I'm a doofus who read the gdb trace from the wrong end - too much python lately :) Nonetheless, the other end of the trace failed in gc as well - and building without GC enabled worked. Here's the trace with debugging enabled: #0 0xff00 in ?? () #1 0x402f0 in collect (young=0x9b538, old=0x9b544) at ./Modules/gcmodule.c:379 #2 0x405a8 in collect_generations () at ./Modules/gcmodule.c:484 #3 0x40624 in _PyGC_Insert (op=0xbc1f24) at ./Modules/gcmodule.c:507 #4 0x5a224 in PyList_New (size=0) at Objects/listobject.c:61 #5 0x21bc8 in eval_code2 (co=0x1cb370, globals=0x21bc0, locals=0x67, args=0x0, argcount=1, kws=0xf89b24, kwcount=0, defs=0x0, defcount=0, closure=0xbc1f24) at Python/ceval.c:1741 Next trick is to rebuild without any optimisation (sigh) as I suspect that it's inlined subtract_refs(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:41:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:41:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-501795 ] pickle/cPickle EOL incompatibility Message-ID: Bugs item #501795, was opened at 2002-01-10 06:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501795&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: James Weatherall (sleeper) >Assigned to: Guido van Rossum (gvanrossum) Summary: pickle/cPickle EOL incompatibility Initial Comment: There seems to be a problem loading pickled data written under Windows (EOL = \r\n) from within Linux (EOL = \n). The problem manifests as being unable to import the required module. Reading Linux pickle data under Windows works fine. e.g. a pickle file containing objects from module Foo will fail to import Foo, because it *actually* tries to import "Foo\r", and obviously can't. (Seems unlikely that noone else has noticed this, so perhaps I'm just being spectacularly dumb.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-10 06:41 Message: Logged In: YES user_id=6380 On Windows, you have to open files containing pickles in binary mode ("rb", "wb"). Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501795&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:49:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:49:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-501830 ] cPickle cannot pickle time.localtime tup Message-ID: Bugs item #501830, was opened at 2002-01-10 06:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501830&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: James Weatherall (sleeper) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle cannot pickle time.localtime tup Initial Comment: time.localtime tuples seem to cause cPickle to enter a recursive loop, producing about 80K of cyclical pickle output before causing the interpreter to dump core. Enclosing calls to time.localtime within tuple() calls fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501830&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:49:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:49:50 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-501831 ] Bit support in "array" module Message-ID: Feature Requests item #501831, was opened at 2002-01-10 06:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=501831&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Bit support in "array" module Initial Comment: I think the standard "array" module should support single bit arrays. In fact, would be very nice a supplementary addition to support arbitrary bit size arrays (for example, 5 bit elements). Of course, single bit should be optimiced, since bitmaps management is a frequent task. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=501831&group_id=5470 From noreply@sourceforge.net Thu Jan 10 14:52:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 06:52:41 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-501831 ] Bit support in "array" module Message-ID: Feature Requests item #501831, was opened at 2002-01-10 06:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=501831&group_id=5470 Category: Python Library Group: None Status: Open Priority: 5 Submitted By: Jesús Cea Avión (jcea) >Assigned to: Martin v. Löwis (loewis) >Summary: Bit support in "array" module Initial Comment: I think the standard "array" module should support single bit arrays. In fact, would be very nice a supplementary addition to support arbitrary bit size arrays (for example, 5 bit elements). Of course, single bit should be optimiced, since bitmaps management is a frequent task. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=501831&group_id=5470 From noreply@sourceforge.net Thu Jan 10 15:54:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 07:54:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-501830 ] cPickle cannot pickle time.localtime tup Message-ID: Bugs item #501830, was opened at 2002-01-10 06:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501830&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: James Weatherall (sleeper) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle cannot pickle time.localtime tup Initial Comment: time.localtime tuples seem to cause cPickle to enter a recursive loop, producing about 80K of cyclical pickle output before causing the interpreter to dump core. Enclosing calls to time.localtime within tuple() calls fixes the problem. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-10 07:53 Message: Logged In: YES user_id=6380 Dup of bug #496873. Semi-fixed in CVS (it now raises a traceback). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501830&group_id=5470 From noreply@sourceforge.net Thu Jan 10 22:26:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 14:26:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-502077 ] signal module should include SIGINFO Message-ID: Bugs item #502077, was opened at 2002-01-10 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502077&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: signal module should include SIGINFO Initial Comment: It would be nice if the signal module included SIGINFO (a BSD thing). #ifdef SIGINFO x = PyInt_FromLong(SIGINFO); PyDict_SetItemString(d, "SIGINFO", x); Py_XDECREF(x); #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502077&group_id=5470 From noreply@sourceforge.net Thu Jan 10 21:55:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 13:55:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-501623 ] traceback problem Message-ID: Bugs item #501623, was opened at 2002-01-09 20:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501623&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: traceback problem Initial Comment: This showed up on the Scons-devel list a few days ago, posted by Anthony Roach (aroach@electriceyeball.com): On Tue, Jan 08, 2002 at 09:11:56AM -0600, Charles Crain wrote: > Python 2.2 is out now, so I downloaded it and ran the test suite. > Everything passed except for errors.py, because it seems they changed the > syntax of the traceback a tad. I saw this too, and as far as I can tell it's a bug in Python 2.2. Basically syntax errors no longer tell you what the file is where the syntax error is, and where the filename used to be it just says . Someone should file a bug report to Python about this... -- Verified: Administrator@MOREPIE e:/temp $ cat > c:/temp/foo.py def foo bar: pass Administrator@MOREPIE e:/temp $ python c:/temp/foo.py File "", line 1 def foo bar: ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 13:55 Message: Logged In: YES user_id=21627 Duplicate of #498828 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501623&group_id=5470 From noreply@sourceforge.net Thu Jan 10 22:49:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 14:49:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python) Message-ID: Bugs item #502085, was opened at 2002-01-10 14:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: pickle problems (with Boost.Python) Initial Comment: Boost.Python (http://www.boost.org/libs/python/doc/index.html) is a popular package for integrating Python and C++. Boost.Python pickle support is broken when using Python 2.2 final, but works with Python 2.2c1. I noticed this difference: diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py /usr/local_cci/Python- 2.2c1/lib/python2.2/pickle.py 26c26 < __version__ = "$Revision: 1.56 $" # Code version --- > __version__ = "$Revision: 1.55 $" # Code version 166,169d165 < if issubclass(t, TypeType): < self.save_global(object) < return I inserted one line in pickle.py: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 165a166 > print "t", t Result: t t object at 0x3ffffe41ae0> Traceback (most recent call last): File "zi", line 9, in ? pstr = pickle.dumps(wd) File "pickle.py", line 974, in dumps Pickler(file, bin).dump(object) File "pickle.py", line 115, in dump self.save(object) File "pickle.py", line 216, in save self.save_reduce(callable, arg_tup, state) File "pickle.py", line 241, in save_reduce save(callable) File "pickle.py", line 167, in save if issubclass(t, TypeType): TypeError: issubclass() arg 1 must be a class The following patch restores backward-compatibility: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 166,168c166,173 < if issubclass(t, TypeType): < self.save_global(object) < return --- > try: > issc = issubclass(t, TypeType) > except TypeError: > pass > else: > if issc: > self.save_global(object) > return Remark: I also noticed that 2.2 cPickle still works for us (double-checked) even though the CVS logs indicate that it was also modified between 2.2c1 and 2.2. Thanks, Ralf ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 From noreply@sourceforge.net Fri Jan 11 05:07:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 21:07:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python) Message-ID: Bugs item #502085, was opened at 2002-01-10 14:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: pickle problems (with Boost.Python) Initial Comment: Boost.Python (http://www.boost.org/libs/python/doc/index.html) is a popular package for integrating Python and C++. Boost.Python pickle support is broken when using Python 2.2 final, but works with Python 2.2c1. I noticed this difference: diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py /usr/local_cci/Python- 2.2c1/lib/python2.2/pickle.py 26c26 < __version__ = "$Revision: 1.56 $" # Code version --- > __version__ = "$Revision: 1.55 $" # Code version 166,169d165 < if issubclass(t, TypeType): < self.save_global(object) < return I inserted one line in pickle.py: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 165a166 > print "t", t Result: t t object at 0x3ffffe41ae0> Traceback (most recent call last): File "zi", line 9, in ? pstr = pickle.dumps(wd) File "pickle.py", line 974, in dumps Pickler(file, bin).dump(object) File "pickle.py", line 115, in dump self.save(object) File "pickle.py", line 216, in save self.save_reduce(callable, arg_tup, state) File "pickle.py", line 241, in save_reduce save(callable) File "pickle.py", line 167, in save if issubclass(t, TypeType): TypeError: issubclass() arg 1 must be a class The following patch restores backward-compatibility: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 166,168c166,173 < if issubclass(t, TypeType): < self.save_global(object) < return --- > try: > issc = issubclass(t, TypeType) > except TypeError: > pass > else: > if issc: > self.save_global(object) > return Remark: I also noticed that 2.2 cPickle still works for us (double-checked) even though the CVS logs indicate that it was also modified between 2.2c1 and 2.2. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-10 21:07 Message: Logged In: YES user_id=6380 Hm, I'm surprised that t (which was returned by type(object)) is not considered a type. Can you explain the Boost metaclass hierarchy a bit so that I can understand how this can work? It was found in the ob_type slot of the object (because that's what type() returns) so it should look a lot like a type! Then why isn't it one? IOW I think that the correct solution would be a change to Boost. But I'm open to persuasion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 From noreply@sourceforge.net Fri Jan 11 06:37:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 22:37:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-500595 ] gettext.install behaves strange Message-ID: Bugs item #500595, was opened at 2002-01-07 13:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500595&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sebastian Rittau (srittau) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.install behaves strange Initial Comment: This is a copy of a bug I sent to the Debian BTS (bug number #127954): --------------------------------------- The behaviour of the gettext.install function is broken in Python 2.1 as well as 2.2. Whenever it tries to open a message catalog that does not exist, an exception is thrown and _ does not get installed in the standard namespace. Consider: srittau@jroger:~$ python Python 2.1.1 (#1, Nov 11 2001, 18:19:24) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import gettext >>> gettext.install('foo') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/gettext.py", line 251, in install translation(domain, localedir).install(unicode) File "/usr/lib/python2.1/gettext.py", line 238, in translation raise IOError(ENOENT, 'No translation file found for domain', domain) IOError: [Errno 2] No translation file found for domain: 'foo' >>> This does even happen if I set LANG to C! Now, I would expect python to continue if a message catalog is not found, as does every other program I know of. A missing catalog is certainly not a critical error. It should at least install _ in the standard name space and throw a custom exception that I can easily ignore if the catalog was not found. I can workaround this behaviour by catching the IOError exception and installing _ in the standard name space by hand. But that's certainly not the solution. --------------------------------------- The Debian maintainer suggested that I bring this up here. He also believes that this is a documentation bug, since this behaviour is documented for gettext.translation(), but not for gettext.install(). But I still believe that this behaviour is wrong, since not finding a translation file is the common case and you will want to continue to use your program and just use the internal strings. - Sebastian ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 22:37 Message: Logged In: YES user_id=21627 Thanks for the report. This is fixed by adding a fallback argument to .translation(), defaulting to 0, for compatibility with the documentation, and by setting fallback to 1 for .install. Committed for 2.3 as gettext.py 1.12, libgettext.tex 1.10, Misc/NEWS 1.349, and for 2.2.1 as 1.11.24.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500595&group_id=5470 From noreply@sourceforge.net Fri Jan 11 07:31:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 23:31:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-459464 ] Math_test overflowerror on sparc64 linux Message-ID: Bugs item #459464, was opened at 2001-09-07 02:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459464&group_id=5470 Category: Extension Modules Group: 3rd Party >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Math_test overflowerror on sparc64 linux Initial Comment: Traceback(most recent call last): testit('asin(-1)',math.asin(-1),-math.pi/2) OverflowError: math range error ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 23:31 Message: Logged In: YES user_id=21627 Re-opening, this can be reproduced on the SF compile farm. It is not a sparc64 issue, since this is all 32-bit userland. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-17 12:45 Message: Logged In: YES user_id=31435 Closed for lack of followup; presumed to be a platform libm bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-13 20:20 Message: Logged In: YES user_id=31435 If there isn't any followup on this by the weekend, I'm going to close it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-10 08:43 Message: Logged In: YES user_id=21627 Also, what compiler did you use? gcc on sparc64 (all versions) has known floating point bugs, so that it is not capable of building reliable 64-bit binaries, see gcc.gnu.org for details. The test works fine for me on Solaris 8, with the Sun WS6U1 compiler. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-07 02:58 Message: Logged In: YES user_id=31435 Needs more info. Which version of Python? If you try asin(-1) in a C program on this box, does the math library set errno? If so, it's a platform C bug, and you should report it to your C vendor (Python doesn't do anything with asin except call the platform asin, and if that sets errno to ERANGE, Python raises OverflowError; asin (-1) should not set errno to ERANGE, but if it does there's nothing Python can do about that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459464&group_id=5470 From noreply@sourceforge.net Fri Jan 11 07:33:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 23:33:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-459464 ] Math_test overflowerror on sparc64 linux Message-ID: Bugs item #459464, was opened at 2001-09-07 02:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459464&group_id=5470 Category: Extension Modules Group: 3rd Party Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Math_test overflowerror on sparc64 linux Initial Comment: Traceback(most recent call last): testit('asin(-1)',math.asin(-1),-math.pi/2) OverflowError: math range error ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 23:33 Message: Logged In: YES user_id=21627 One further piece of information: If mathmodule is linked into the interpreter, the test passes fine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 23:31 Message: Logged In: YES user_id=21627 Re-opening, this can be reproduced on the SF compile farm. It is not a sparc64 issue, since this is all 32-bit userland. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-17 12:45 Message: Logged In: YES user_id=31435 Closed for lack of followup; presumed to be a platform libm bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-13 20:20 Message: Logged In: YES user_id=31435 If there isn't any followup on this by the weekend, I'm going to close it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-10 08:43 Message: Logged In: YES user_id=21627 Also, what compiler did you use? gcc on sparc64 (all versions) has known floating point bugs, so that it is not capable of building reliable 64-bit binaries, see gcc.gnu.org for details. The test works fine for me on Solaris 8, with the Sun WS6U1 compiler. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-07 02:58 Message: Logged In: YES user_id=31435 Needs more info. Which version of Python? If you try asin(-1) in a C program on this box, does the math library set errno? If so, it's a platform C bug, and you should report it to your C vendor (Python doesn't do anything with asin except call the platform asin, and if that sets errno to ERANGE, Python raises OverflowError; asin (-1) should not set errno to ERANGE, but if it does there's nothing Python can do about that). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459464&group_id=5470 From noreply@sourceforge.net Fri Jan 11 07:38:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Jan 2002 23:38:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-502077 ] signal module should include SIGINFO Message-ID: Bugs item #502077, was opened at 2002-01-10 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502077&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: signal module should include SIGINFO Initial Comment: It would be nice if the signal module included SIGINFO (a BSD thing). #ifdef SIGINFO x = PyInt_FromLong(SIGINFO); PyDict_SetItemString(d, "SIGINFO", x); Py_XDECREF(x); #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 23:38 Message: Logged In: YES user_id=21627 Can you produce a complete list of signals that are available in the most recent BSD but not recognized by Python? Experience tells that platform-specific things always come in larger sets. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502077&group_id=5470 From noreply@sourceforge.net Fri Jan 11 08:46:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 00:46:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Fri Jan 11 10:19:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 02:19:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-502255 ] leading '\xff\xfe' w/ s.encode('utf-16') Message-ID: Bugs item #502255, was opened at 2002-01-11 02:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502255&group_id=5470 Category: Unicode Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Niels Mache (nielsmache) Assigned to: M.-A. Lemburg (lemburg) Summary: leading '\xff\xfe' w/ s.encode('utf-16') Initial Comment: The UTF-16 encode method returns '\xff\xfe' at the start of the result string: >>> s = '' >>> s.encode('utf-16') '\xff\xfe' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502255&group_id=5470 From noreply@sourceforge.net Fri Jan 11 10:42:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 02:42:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-502255 ] leading '\xff\xfe' w/ s.encode('utf-16') Message-ID: Bugs item #502255, was opened at 2002-01-11 02:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502255&group_id=5470 Category: Unicode Group: Python 2.1.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Niels Mache (nielsmache) Assigned to: M.-A. Lemburg (lemburg) Summary: leading '\xff\xfe' w/ s.encode('utf-16') Initial Comment: The UTF-16 encode method returns '\xff\xfe' at the start of the result string: >>> s = '' >>> s.encode('utf-16') '\xff\xfe' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-11 02:42 Message: Logged In: YES user_id=38388 That's not a bug. Use 'utf-16-le' or 'utf-16-be' if you want to avoid the BOM mark. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502255&group_id=5470 From noreply@sourceforge.net Fri Jan 11 15:46:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 07:46:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Fri Jan 11 16:19:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 08:19:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Fri Jan 11 16:41:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 08:41:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-01-11 08:41 Message: Logged In: YES user_id=60903 I couldn't reproduce the original error in squishdot-1.3 with CVS 20020107 and zope-2.5beta3. Neither with the import of the zope tutorial. The person who did get this error (L. Vogtmann) couldn't reproduce this error as well with the updated python version. I got no response from the original bug submitter. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:28 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:27 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:26 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Fri Jan 11 17:17:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 09:17:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python) Message-ID: Bugs item #502085, was opened at 2002-01-10 14:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: pickle problems (with Boost.Python) Initial Comment: Boost.Python (http://www.boost.org/libs/python/doc/index.html) is a popular package for integrating Python and C++. Boost.Python pickle support is broken when using Python 2.2 final, but works with Python 2.2c1. I noticed this difference: diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py /usr/local_cci/Python- 2.2c1/lib/python2.2/pickle.py 26c26 < __version__ = "$Revision: 1.56 $" # Code version --- > __version__ = "$Revision: 1.55 $" # Code version 166,169d165 < if issubclass(t, TypeType): < self.save_global(object) < return I inserted one line in pickle.py: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 165a166 > print "t", t Result: t t object at 0x3ffffe41ae0> Traceback (most recent call last): File "zi", line 9, in ? pstr = pickle.dumps(wd) File "pickle.py", line 974, in dumps Pickler(file, bin).dump(object) File "pickle.py", line 115, in dump self.save(object) File "pickle.py", line 216, in save self.save_reduce(callable, arg_tup, state) File "pickle.py", line 241, in save_reduce save(callable) File "pickle.py", line 167, in save if issubclass(t, TypeType): TypeError: issubclass() arg 1 must be a class The following patch restores backward-compatibility: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 166,168c166,173 < if issubclass(t, TypeType): < self.save_global(object) < return --- > try: > issc = issubclass(t, TypeType) > except TypeError: > pass > else: > if issc: > self.save_global(object) > return Remark: I also noticed that 2.2 cPickle still works for us (double-checked) even though the CVS logs indicate that it was also modified between 2.2c1 and 2.2. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-01-11 09:17 Message: Logged In: YES user_id=71407 > IOW I think that the correct solution would be a change to > Boost. But I'm open to persuasion. In principle I agree with you, but here are a few arguments to justify the easy fix: - The old Boost.Python metaclass system is a dead branch. We would prefer to concentrate our time on the ongoing rewrite of Boost.Python which will be fully based on the new Python 2.2 type system. - A significant number of people are using released versions of Boost(.Python). If the easy fix is integrated in Python 2.2.1, they could continue to use what they have. - Other people might be affected by your change. The suggested solution will restore backward-compatibility with more people's existing code. - This is more a question: can you envision that the suggested fix has negative side-effects? Thanks, Ralf ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-10 21:07 Message: Logged In: YES user_id=6380 Hm, I'm surprised that t (which was returned by type(object)) is not considered a type. Can you explain the Boost metaclass hierarchy a bit so that I can understand how this can work? It was found in the ob_type slot of the object (because that's what type() returns) so it should look a lot like a type! Then why isn't it one? IOW I think that the correct solution would be a change to Boost. But I'm open to persuasion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 From noreply@sourceforge.net Fri Jan 11 18:39:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 10:39:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python) Message-ID: Bugs item #502085, was opened at 2002-01-10 14:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: pickle problems (with Boost.Python) Initial Comment: Boost.Python (http://www.boost.org/libs/python/doc/index.html) is a popular package for integrating Python and C++. Boost.Python pickle support is broken when using Python 2.2 final, but works with Python 2.2c1. I noticed this difference: diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py /usr/local_cci/Python- 2.2c1/lib/python2.2/pickle.py 26c26 < __version__ = "$Revision: 1.56 $" # Code version --- > __version__ = "$Revision: 1.55 $" # Code version 166,169d165 < if issubclass(t, TypeType): < self.save_global(object) < return I inserted one line in pickle.py: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 165a166 > print "t", t Result: t t object at 0x3ffffe41ae0> Traceback (most recent call last): File "zi", line 9, in ? pstr = pickle.dumps(wd) File "pickle.py", line 974, in dumps Pickler(file, bin).dump(object) File "pickle.py", line 115, in dump self.save(object) File "pickle.py", line 216, in save self.save_reduce(callable, arg_tup, state) File "pickle.py", line 241, in save_reduce save(callable) File "pickle.py", line 167, in save if issubclass(t, TypeType): TypeError: issubclass() arg 1 must be a class The following patch restores backward-compatibility: % diff /usr/local_cci/Python- 2.2/lib/python2.2/pickle.py . 166,168c166,173 < if issubclass(t, TypeType): < self.save_global(object) < return --- > try: > issc = issubclass(t, TypeType) > except TypeError: > pass > else: > if issc: > self.save_global(object) > return Remark: I also noticed that 2.2 cPickle still works for us (double-checked) even though the CVS logs indicate that it was also modified between 2.2c1 and 2.2. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 10:39 Message: Logged In: YES user_id=6380 Ah, I didn't realize this was the old Boost. I should have (the new one only runs on Python 2.2). I'll think about it. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-01-11 09:17 Message: Logged In: YES user_id=71407 > IOW I think that the correct solution would be a change to > Boost. But I'm open to persuasion. In principle I agree with you, but here are a few arguments to justify the easy fix: - The old Boost.Python metaclass system is a dead branch. We would prefer to concentrate our time on the ongoing rewrite of Boost.Python which will be fully based on the new Python 2.2 type system. - A significant number of people are using released versions of Boost(.Python). If the easy fix is integrated in Python 2.2.1, they could continue to use what they have. - Other people might be affected by your change. The suggested solution will restore backward-compatibility with more people's existing code. - This is more a question: can you envision that the suggested fix has negative side-effects? Thanks, Ralf ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-10 21:07 Message: Logged In: YES user_id=6380 Hm, I'm surprised that t (which was returned by type(object)) is not considered a type. Can you explain the Boost metaclass hierarchy a bit so that I can understand how this can work? It was found in the ob_type slot of the object (because that's what type() returns) so it should look a lot like a type! Then why isn't it one? IOW I think that the correct solution would be a change to Boost. But I'm open to persuasion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470 From noreply@sourceforge.net Fri Jan 11 21:16:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 13:16:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Fri Jan 11 21:21:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 13:21:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings Message-ID: Bugs item #502503, was opened at 2002-01-11 13:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Kelley (wc2so1) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pickle interns strings Initial Comment: Pickle (and cPickle) use eval to reconstruct string variables from the stored format. Eval is used because it correctly reconstructs the repr of a string back into the original string object by translating all the appropriately escape characters like "\m" and "\n" There is an side effect in that eval interns string variables for faster lookup. This causes the following sample code to unexpectedly grow in memory consumption: import pickle import random import string def genstring(length=100): s = [random.choice(string.letters) for x in range(length)] return "".join(s) def test(): while 1: s = genstring() dump = pickle.dumps(s) s2 = pickle.loads(dump) assert s == s2 test() Note that all strings are not interned, just ones that, as Tim Peters once said, "look like", variable names. The above example is contrived to generate a lot of different names that "look like" variables names but since this has happened in practice it probably should documented. Interestingly, by inserting s.append(" ") before return "".join(s) The memory consumption is not seen because the names no longer "look like" variable names. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470 From noreply@sourceforge.net Fri Jan 11 21:36:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 13:36:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings Message-ID: Bugs item #502503, was opened at 2002-01-11 13:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Kelley (wc2so1) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pickle interns strings Initial Comment: Pickle (and cPickle) use eval to reconstruct string variables from the stored format. Eval is used because it correctly reconstructs the repr of a string back into the original string object by translating all the appropriately escape characters like "\m" and "\n" There is an side effect in that eval interns string variables for faster lookup. This causes the following sample code to unexpectedly grow in memory consumption: import pickle import random import string def genstring(length=100): s = [random.choice(string.letters) for x in range(length)] return "".join(s) def test(): while 1: s = genstring() dump = pickle.dumps(s) s2 = pickle.loads(dump) assert s == s2 test() Note that all strings are not interned, just ones that, as Tim Peters once said, "look like", variable names. The above example is contrived to generate a lot of different names that "look like" variables names but since this has happened in practice it probably should documented. Interestingly, by inserting s.append(" ") before return "".join(s) The memory consumption is not seen because the names no longer "look like" variable names. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:36 Message: Logged In: YES user_id=31435 Noting that Security Geeks are uncomfortable with using eval () for this purpose regardless. Would be good if Python got refactored so that pickle and cPickle and the front end all called a new routine that simply parsed the escape sequences in a character buffer, returning a Python string object. Don't ask me about Unicode . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470 From noreply@sourceforge.net Fri Jan 11 23:26:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 15:26:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-502544 ] __slots__ undocumented Message-ID: Bugs item #502544, was opened at 2002-01-11 15:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502544&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Frank J. Tobin (ftobin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __slots__ undocumented Initial Comment: Simply put, there is no documentation describing __slots__. A mere grep shows this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502544&group_id=5470 From noreply@sourceforge.net Fri Jan 11 23:40:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 15:40:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-502544 ] __slots__ undocumented Message-ID: Bugs item #502544, was opened at 2002-01-11 15:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502544&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Frank J. Tobin (ftobin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __slots__ undocumented Initial Comment: Simply put, there is no documentation describing __slots__. A mere grep shows this. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 15:40 Message: Logged In: YES user_id=6380 Not in the core docs, but in the mean time there's a lot of detail on __slots__ in http://www.python.org/2.2/descrintro.html. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502544&group_id=5470 From noreply@sourceforge.net Sat Jan 12 00:04:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 16:04:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-502557 ] hmac module: default to sha, not md5 Message-ID: Bugs item #502557, was opened at 2002-01-11 16:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502557&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: hmac module: default to sha, not md5 Initial Comment: Currently the hmac module defaults to using the md5 module as its "digest module" (digestmod). I think a better idea is to default to sha instead for the following reasons: * Unlike SHA-1, some partial breaks have been found in the security of MD5. Section 1 of RFC 2104 describes this and admits that SHA-1 is a cryptographically stronger hash function. * There is nothing in RFC 2104 that specifies or even alludes to which hash function should be used by default. So, given the weaknesses in MD5 and the fact that we already have SHA-1 available, I think it makes sense to use that by default instead. I'll contribute a patch for this change if you'd like. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502557&group_id=5470 From noreply@sourceforge.net Sat Jan 12 00:57:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 16:57:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-11 16:57 Message: Logged In: YES user_id=29957 In that case, I'm closing it as "Works for me". ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-11 08:41 Message: Logged In: YES user_id=60903 I couldn't reproduce the original error in squishdot-1.3 with CVS 20020107 and zope-2.5beta3. Neither with the import of the zope tutorial. The person who did get this error (L. Vogtmann) couldn't reproduce this error as well with the updated python version. I got no response from the original bug submitter. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:28 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:27 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:26 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Sat Jan 12 01:05:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Jan 2002 17:05:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 17:05 Message: Logged In: YES user_id=21627 Tim, I'm not surprised that raising SystemExit in a thread fails to exit Python; the reason simply is that threadmodule.c:t_bootstrap choses to ignore PyExc_SystemExit, when it instead should invoke PyErr_PrintEx instead. The bug is obviously that exit_thread also raises SystemExit, when people apparently really want sys.exit and thread.exit to be two different things. So I think thread.exit should raise ThreadExit, and raising SystemExit in a thread should cause Py_Exit to be invoked (along with all other necessary cleanup). In short, 2.12 of threadmodule.c was wrong, IMO. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Sat Jan 12 10:03:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Jan 2002 02:03:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 7 Submitted By: Konrad Hinsen (hinsen) >Assigned to: Martin v. Löwis (loewis) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2002-01-09 05:32 Message: Logged In: YES user_id=11850 Including in Python.h sounds like a good solution to me. But first of all, please change the comment for _POSIX_THREADS in pyconfig.h. I am probably not the only one to use the Python sources for documentation purposes - contrary to POSIX documents, which I have never seen. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 21:36 Message: Logged In: YES user_id=21627 Including in Python.h should be possible. Of course, it may lead to breakage of existing extensions, since unistd.h may drag in (almost) arbitrary additional #defines and other global names, which could then confuse the extension code. One may argue that any such extension code would be already incorrect if it cannot stand inclusion of on Unix. So the risk should be very small. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 14:05 Message: Logged In: YES user_id=6380 Can't we #include in Python.h, if it exists? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:55 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in the extension modules. According to POSIX, an implementation (i.e. OS and C compiler) shall define _POSIX_THREADS in if threads are supported. Python 2.1 was always defining this, which was an error because it might have conflicted with the operating system settings. Python 2.2 only defines it if it finds a specific bug in the implementation: namely, if the system provides posix threads, but does not declare so in unistd.h. So the bug is in the extension modules: they must include to get _POSIX_THREADS. It is safe to include after including Python.h and checking HAVE_UNISTD_H. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Sat Jan 12 11:16:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Jan 2002 03:16:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-500924 ] _POSIX_THREADS not set in pyconfig.h Message-ID: Bugs item #500924, was opened at 2002-01-08 09:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 Category: Build Group: Python 2.2.1 candidate >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Konrad Hinsen (hinsen) Assigned to: Martin v. Löwis (loewis) Summary: _POSIX_THREADS not set in pyconfig.h Initial Comment: When building Python 2.2 under Linux (RedHat 7.1), _POSIX_THREADS remains undefined in pyconfig.h although Posix threads are used. In Python 2.1 it was still set. I haven't found any adverse effects in Python itself, but threaded extension modules that make pthread calls don't compile. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-12 03:16 Message: Logged In: YES user_id=21627 Fixed for both Python 2.3 and 2.2. Since is now included in Python.h, all other includes are removed. Revisions for mainline: Python.h 2.41 _hotshot.c 1.12 bsddbmodule.c 1.31 fcntlmodule.c 2.33 getpath.c 1.41 linuxaudiodev.c 2.17 main.c 1.62 mmapmodule.c 2.36 posixmodule.c 2.218 readline.c 2.42 resource.c 2.20 rgbimgmodule.c 2.23 selectmodule.c 2.60 sgimodule.c 1.17 signalmodule.c 2.61 socketmodule.c 1.202 sunaudiodev.c 1.27 termios.c 2.32 timemodule.c 2.119 fileobject.c 2.143 getpathp.c 1.26 intrcheck.c 2.44 bltinmodule.c 2.247 dynload_beos.c 2.7 frozenmain.c 2.27 import.c 2.193 pythonrun.c 2.154 sysmodule.c 2.99 thread.c 2.40 thread_solaris.h 2.17 For 2.2: Python.h 2.40.6.1 _hotshot.c 1.11.6.1 bsddbmodule.c 1.30.6.1 fcntlmodule.c 2.31.18.2 getpath.c 1.40.6.1 linuxaudiodev.c 2.16.6.1 main.c 1.61.6.1 mmapmodule.c 2.35.6.1 posixmodule.c 2.216.4.2 readline.c 2.41.6.1 resource.c 2.19.12.1 rgbimgmodule.c 2.22.26.1 selectmodule.c 2.59.6.1 sgimodule.c 1.16.26.1 signalmodule.c 2.60.10.1 socketmodule.c 1.200.6.2 sunaudiodev.c 1.26.6.1 termios.c 2.31.18.1 timemodule.c 2.118.6.1 fileobject.c 2.141.6.1 getpathp.c 1.25.12.1 intrcheck.c 2.43.24.1 bltinmodule.c 2.246.4.1 dynload_beos.c 2.6.6.1 frozenmain.c 2.26.16.1 import.c 2.192.6.1 pythonrun.c 2.153.6.1 sysmodule.c 2.98.6.1 thread.c 2.39.10.1 thread_solaris.h 2.16.10.1 ---------------------------------------------------------------------- Comment By: Konrad Hinsen (hinsen) Date: 2002-01-09 05:32 Message: Logged In: YES user_id=11850 Including in Python.h sounds like a good solution to me. But first of all, please change the comment for _POSIX_THREADS in pyconfig.h. I am probably not the only one to use the Python sources for documentation purposes - contrary to POSIX documents, which I have never seen. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 21:36 Message: Logged In: YES user_id=21627 Including in Python.h should be possible. Of course, it may lead to breakage of existing extensions, since unistd.h may drag in (almost) arbitrary additional #defines and other global names, which could then confuse the extension code. One may argue that any such extension code would be already incorrect if it cannot stand inclusion of on Unix. So the risk should be very small. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 14:05 Message: Logged In: YES user_id=6380 Can't we #include in Python.h, if it exists? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 13:55 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in the extension modules. According to POSIX, an implementation (i.e. OS and C compiler) shall define _POSIX_THREADS in if threads are supported. Python 2.1 was always defining this, which was an error because it might have conflicted with the operating system settings. Python 2.2 only defines it if it finds a specific bug in the implementation: namely, if the system provides posix threads, but does not declare so in unistd.h. So the bug is in the extension modules: they must include to get _POSIX_THREADS. It is safe to include after including Python.h and checking HAVE_UNISTD_H. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 12:13 Message: Logged In: YES user_id=6380 I don't know anything about this area of life, but I surmise it's a bug that ought to be fixed before we release 2.2.1, hence I'm setting the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500924&group_id=5470 From noreply@sourceforge.net Sat Jan 12 11:44:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Jan 2002 03:44:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-502077 ] signal module should include SIGINFO Message-ID: Bugs item #502077, was opened at 2002-01-10 14:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502077&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: signal module should include SIGINFO Initial Comment: It would be nice if the signal module included SIGINFO (a BSD thing). #ifdef SIGINFO x = PyInt_FromLong(SIGINFO); PyDict_SetItemString(d, "SIGINFO", x); Py_XDECREF(x); #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-12 03:44 Message: Logged In: YES user_id=21627 It seems that it is really just SIGINFO that is missing; fixed in signalmodule.c 2.62. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-10 23:38 Message: Logged In: YES user_id=21627 Can you produce a complete list of signals that are available in the most recent BSD but not recognized by Python? Experience tells that platform-specific things always come in larger sets. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502077&group_id=5470 From noreply@sourceforge.net Sat Jan 12 20:03:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Jan 2002 12:03:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-12 12:03 Message: Logged In: YES user_id=6380 (1) It's too late to change the meaning of SystemExit -- people are relying on SystemExit exiting the thread only. (2) If we provide a way for a thread to exit the whole program, how will finally clauses in other threads (including the main thread) be executed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 17:05 Message: Logged In: YES user_id=21627 Tim, I'm not surprised that raising SystemExit in a thread fails to exit Python; the reason simply is that threadmodule.c:t_bootstrap choses to ignore PyExc_SystemExit, when it instead should invoke PyErr_PrintEx instead. The bug is obviously that exit_thread also raises SystemExit, when people apparently really want sys.exit and thread.exit to be two different things. So I think thread.exit should raise ThreadExit, and raising SystemExit in a thread should cause Py_Exit to be invoked (along with all other necessary cleanup). In short, 2.12 of threadmodule.c was wrong, IMO. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Sun Jan 13 12:46:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 04:46:44 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-502981 ] should be able to use "else:" with "for" Message-ID: Feature Requests item #502981, was opened at 2002-01-13 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=502981&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: Nobody/Anonymous (nobody) Summary: should be able to use "else:" with "for" Initial Comment: I'd like to be able to do use "else" to catch cases where a "for" iterates over an empty list. For example, it should behave as follows: >>> l = [ "a", "b" ] >>> for i in l: ... print i ... else: ... print "the list is empty" ... a b >>> l = [] >>> for i in l: ... print i ... else: ... print "the list is empty" ... the list is empty >>> As it currently functions, in Python 2.1.1, the "else" clause always gets executed. However, I don't think this behavior is specified, so I'd expect it'd be alright to change it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=502981&group_id=5470 From noreply@sourceforge.net Sun Jan 13 12:50:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 04:50:17 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-502981 ] should be able to use "else:" with "for" Message-ID: Feature Requests item #502981, was opened at 2002-01-13 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=502981&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: Nobody/Anonymous (nobody) >Summary: should be able to use "else:" with "for" Initial Comment: I'd like to be able to do use "else" to catch cases where a "for" iterates over an empty list. For example, it should behave as follows: >>> l = [ "a", "b" ] >>> for i in l: ... print i ... else: ... print "the list is empty" ... a b >>> l = [] >>> for i in l: ... print i ... else: ... print "the list is empty" ... the list is empty >>> As it currently functions, in Python 2.1.1, the "else" clause always gets executed. However, I don't think this behavior is specified, so I'd expect it'd be alright to change it. ---------------------------------------------------------------------- >Comment By: Matthew Gruenke (mgruenke) Date: 2002-01-13 04:50 Message: Logged In: YES user_id=343027 phoey. The formatter tried to be intelligent, and gobbled all my indentation. Hopefully, you get the point, anyhow. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=502981&group_id=5470 From noreply@sourceforge.net Sun Jan 13 14:36:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 06:36:08 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-502981 ] should be able to use "else:" with "for" Message-ID: Feature Requests item #502981, was opened at 2002-01-13 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=502981&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Matthew Gruenke (mgruenke) >Assigned to: Guido van Rossum (gvanrossum) >Summary: should be able to use "else:" with "for" Initial Comment: I'd like to be able to do use "else" to catch cases where a "for" iterates over an empty list. For example, it should behave as follows: >>> l = [ "a", "b" ] >>> for i in l: ... print i ... else: ... print "the list is empty" ... a b >>> l = [] >>> for i in l: ... print i ... else: ... print "the list is empty" ... the list is empty >>> As it currently functions, in Python 2.1.1, the "else" clause always gets executed. However, I don't think this behavior is specified, so I'd expect it'd be alright to change it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 06:36 Message: Logged In: YES user_id=6380 Even if it wasn't specified (which I don't believe -- you probably just aren't very good at language lawyering yet :-), it's been this way for over 10 years and would break tons of code if it was changed. Even if it was OK to change, I wouldn't change it because I think the existing behavior is more useful; treating the empty list differently would cause hidden bugs in programs. IOW, I'm rejecting this. ---------------------------------------------------------------------- Comment By: Matthew Gruenke (mgruenke) Date: 2002-01-13 04:50 Message: Logged In: YES user_id=343027 phoey. The formatter tried to be intelligent, and gobbled all my indentation. Hopefully, you get the point, anyhow. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=502981&group_id=5470 From noreply@sourceforge.net Sun Jan 13 18:09:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 10:09:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Sun Jan 13 21:33:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 13:33:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Sun Jan 13 22:28:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 14:28:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-503091 ] new.instancemethod fails for new classes Message-ID: Bugs item #503091, was opened at 2002-01-13 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503091&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Pedro Rodriguez (pedro_rodriguez) Assigned to: Nobody/Anonymous (nobody) Summary: new.instancemethod fails for new classes Initial Comment: The following code exhibit the problem : import new # OK def n(self): pass class A: def f(self): pass print new.instancemethod(n, None, A) # FAILS with # Traceback (most recent call last): # File "bug.py", line 18, in ? # print new.instancemethod(n, None, B) # TypeError: instancemethod() argument 3 must be class, # not type def m(self): pass class B(object): def f(self): pass print new.instancemethod(n, None, B) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503091&group_id=5470 From noreply@sourceforge.net Sun Jan 13 22:35:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 14:35:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Mon Jan 14 04:46:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 20:46:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Mon Jan 14 08:40:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 00:40:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-14 00:40 Message: Logged In: YES user_id=21627 On (1): This is quite unfortunate, as I do think sys.exit and thread.exit should do different things. There would be approaches of further subclassing SystemExit; preserving the property that raising SystemExit in a thread exits the thread only - would such a solution be acceptable? On (2): This is no different from raising SystemExit in the main thread, which also does not invoke finally clauses in other threads. I don't think there can be a complete, reliable implementation of thread cancellation, only a best-effort approach. For POSIX, I'd suggest sending SIGUSR2 to each thread through pthread_kill. We might need to add a mechanism indicating whether a thread is ready to be cancelled, similar to the POSIX cancellation points. That would prevent the signal from arriving in an arbitrary library function, and defer thread termination until the library function completes. For blocking system calls, sending signals would need to be activated explicitly, to allow aborting them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-12 12:03 Message: Logged In: YES user_id=6380 (1) It's too late to change the meaning of SystemExit -- people are relying on SystemExit exiting the thread only. (2) If we provide a way for a thread to exit the whole program, how will finally clauses in other threads (including the main thread) be executed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 17:05 Message: Logged In: YES user_id=21627 Tim, I'm not surprised that raising SystemExit in a thread fails to exit Python; the reason simply is that threadmodule.c:t_bootstrap choses to ignore PyExc_SystemExit, when it instead should invoke PyErr_PrintEx instead. The bug is obviously that exit_thread also raises SystemExit, when people apparently really want sys.exit and thread.exit to be two different things. So I think thread.exit should raise ThreadExit, and raising SystemExit in a thread should cause Py_Exit to be invoked (along with all other necessary cleanup). In short, 2.12 of threadmodule.c was wrong, IMO. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Mon Jan 14 13:04:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 05:04:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Mon Jan 14 22:21:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 14:21:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-501164 ] 2.2 on linux SEGV sometimes Message-ID: Bugs item #501164, was opened at 2002-01-08 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: MATSUI Tetsushi (tetsushi) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 on linux SEGV sometimes Initial Comment: I am using Python 2.2. The execution with pure python scripts suddenly stops after several hours or a few days. With the latest core I run gdb, it says: Program terminated with signal 11, Segmentation fault. and the head of bt is like this: #0 0x80afb1e in binary_op1 (v=0x8dc0f54, w=0x8c641bc, op_slot=4) at Objects/abstract.c:340 #1 0x80b2537 in PyNumber_Subtract (v=0x8dc0f54, w=0x8c641bc) at Objects/abstract.c:392 #2 0x8079f27 in eval_frame (f=0x820c1fc) at Python/ceval.c:988 #3 0x807cd50 in PyEval_EvalCodeEx (co=0x81cf608, globals=0x81d5214, locals=0x0, args=0x8202fc4, argcount=5, kws=0x8202fd8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2574 #4 0x807f41c in fast_function (func=0x81e4584, pp_stack=0xbfffe474, n=5, na=5, nk=0) at Python/ceval.c:3150 Thanks, tetsushi ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-14 14:21 Message: Logged In: YES user_id=21627 I cannot reproduce this: >>> from alib import * >>> MPQS(30).run() starting MPQS 10 {10: 1, 3: 1}>>> MPQS(3000000000000000000000000000000000).run() starting MPQS 1000000000000000000000000000000000 {1000000000000000000000000000000000L: 1, 3: 1} Can you please give the *precise* sequence of commands to make this crash? ---------------------------------------------------------------------- Comment By: MATSUI Tetsushi (tetsushi) Date: 2002-01-08 23:00 Message: Logged In: YES user_id=421269 OK, I attach the main script. (Maybe the 1659-th line is the stopping point.) It consists of many factoring or primality testing functions and classes, and the stopping point I suspect is in the class MPQS. To run the algorithm MPQS(n).run() where n is about 30 decimal digit composite. The length of stack trace is 53. The last 3 are like this: #50 0x8053fcb in Py_Main (argc=5, argv=0xbffff644) at Modules/main.c:369 #51 0x8053a47 in main (argc=5, argv=0xbffff644) at Modules/python.c:10 #52 0x4004ca49 in Letext () Thanks, tetsushi. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:00 Message: Logged In: YES user_id=6380 Can you attach the script, any input data it needs, and instructions for running it? Otherwise there's no hope in debugging this. Also, how long is the stack? Could it be a stack overflow? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 From noreply@sourceforge.net Mon Jan 14 22:34:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 14:34:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-503570 ] Python 2.1.2c1 missing a bugfix Message-ID: Bugs item #503570, was opened at 2002-01-14 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503570&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Shane Hathaway (hathawsh) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1.2c1 missing a bugfix Initial Comment: There was a change made recently to importdl.c to correct a bug that happens when extensions defined in a package try to import another extension. The bugfix is not in Python 2.1.2c1. See patch #471839. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503570&group_id=5470 From noreply@sourceforge.net Mon Jan 14 22:44:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 14:44:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-503570 ] Python 2.1.2c1 missing a bugfix Message-ID: Bugs item #503570, was opened at 2002-01-14 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503570&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None >Priority: 7 Submitted By: Shane Hathaway (hathawsh) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Python 2.1.2c1 missing a bugfix Initial Comment: There was a change made recently to importdl.c to correct a bug that happens when extensions defined in a package try to import another extension. The bugfix is not in Python 2.1.2c1. See patch #471839. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503570&group_id=5470 From noreply@sourceforge.net Tue Jan 15 09:57:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 01:57:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-477487 ] Build Problems on AIX 4.3.3 Message-ID: Bugs item #477487, was opened at 2001-11-02 03:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Build Problems on AIX 4.3.3 Initial Comment: Problems in building Python 2.2b1 in AIX 4.3.3 with IBM vac++ compiler. I think the problem is not compiler specific. The build tries to execute the following code: ../Modules/makexp_aix Modules/python.exp "" libpython2.2.a; -Wl,-bE:Modules/python.exp -lld -o python \ Modules/ccpython.o \ libpython2.2.a -ldl -lpthread -lm The first part executes ok: ../Modules/makexp_aix Modules/python.exp "" libpython2.2.a In the second part the call to the linker is missing. Something like : xlC_r -Wl,-bE:Modules/python.exp -lld -o python Modules/ccpython.o libpython2.2.a -ldl -lpthread -lm dose the job ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-15 01:57 Message: Logged In: YES user_id=418821 The following lines in the configure script (the check for LINKCC) should be changed: case $ac_sys_system in AIX*) LINKCC="\/Modules/makexp_aix Modules/python.exp \\ \; $(LINKCC)";; The brackets around the $(LINKCC) should be removed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477487&group_id=5470 From noreply@sourceforge.net Tue Jan 15 13:11:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 05:11:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-503837 ] type.__module__ problems (again?) Message-ID: Bugs item #503837, was opened at 2002-01-15 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Nobody/Anonymous (nobody) Summary: type.__module__ problems (again?) Initial Comment: Gelukkig nieuwjaar, This is probably related to previous bug reports on type.__module__. Given --- A.py --- class meta1(type): def __new__(tp, name, bases, attr): return type.__new__(tp, name, bases, attr) class meta2(type): pass --- B.py --- import A class B1(object): __metaclass__ = A.meta1 class B2(object): __metaclass__ = A.meta2 ------------ I get the following session. Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import B >>> B.B1.__module__ 'A' >>> B.B2.__module__ 'B' Among others, this problem causes pydoc to only display documentation for B2 as part of the docs for module B. Presumably, the behaviour for B2 is correct. Regards, Roeland Rengelink ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 From noreply@sourceforge.net Tue Jan 15 17:33:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 09:33:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-503837 ] type.__module__ problems (again?) Message-ID: Bugs item #503837, was opened at 2002-01-15 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roeland Rengelink (rengelink) >Assigned to: Guido van Rossum (gvanrossum) Summary: type.__module__ problems (again?) Initial Comment: Gelukkig nieuwjaar, This is probably related to previous bug reports on type.__module__. Given --- A.py --- class meta1(type): def __new__(tp, name, bases, attr): return type.__new__(tp, name, bases, attr) class meta2(type): pass --- B.py --- import A class B1(object): __metaclass__ = A.meta1 class B2(object): __metaclass__ = A.meta2 ------------ I get the following session. Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import B >>> B.B1.__module__ 'A' >>> B.B2.__module__ 'B' Among others, this problem causes pydoc to only display documentation for B2 as part of the docs for module B. Presumably, the behaviour for B2 is correct. Regards, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:33 Message: Logged In: YES user_id=6380 You're right. This is because __module__ is taken from the globals of the currently executing Python code. This is clearly a bug. I'll have to think about how to fix it -- maybe the class statement will have to set it. I can't find the other bug reports related to __module__; the SF search box apparently searches for "module" when I type that in the search box, and that hits about every other bug report ever submitted, including closed ones. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 From noreply@sourceforge.net Tue Jan 15 17:38:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 09:38:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-477487 ] Build Problems on AIX 4.3.3 Message-ID: Bugs item #477487, was opened at 2001-11-02 03:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Build Problems on AIX 4.3.3 Initial Comment: Problems in building Python 2.2b1 in AIX 4.3.3 with IBM vac++ compiler. I think the problem is not compiler specific. The build tries to execute the following code: ../Modules/makexp_aix Modules/python.exp "" libpython2.2.a; -Wl,-bE:Modules/python.exp -lld -o python \ Modules/ccpython.o \ libpython2.2.a -ldl -lpthread -lm The first part executes ok: ../Modules/makexp_aix Modules/python.exp "" libpython2.2.a In the second part the call to the linker is missing. Something like : xlC_r -Wl,-bE:Modules/python.exp -lld -o python Modules/ccpython.o libpython2.2.a -ldl -lpthread -lm dose the job ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:38 Message: Logged In: YES user_id=6380 srubben: I don't understand your suggestion. What brackets? Can you type in the correct line? ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-15 01:57 Message: Logged In: YES user_id=418821 The following lines in the configure script (the check for LINKCC) should be changed: case $ac_sys_system in AIX*) LINKCC="\/Modules/makexp_aix Modules/python.exp \\ \; $(LINKCC)";; The brackets around the $(LINKCC) should be removed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477487&group_id=5470 From noreply@sourceforge.net Tue Jan 15 17:46:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 09:46:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None >Priority: 1 Submitted By: Jason Cowley (sachmoz) >Assigned to: Guido van Rossum (gvanrossum) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Tue Jan 15 18:17:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 10:17:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 1 Submitted By: Jason Cowley (sachmoz) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Tue Jan 15 19:21:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 11:21:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-503091 ] new.instancemethod fails for new classes Message-ID: Bugs item #503091, was opened at 2002-01-13 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503091&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pedro Rodriguez (pedro_rodriguez) >Assigned to: Guido van Rossum (gvanrossum) Summary: new.instancemethod fails for new classes Initial Comment: The following code exhibit the problem : import new # OK def n(self): pass class A: def f(self): pass print new.instancemethod(n, None, A) # FAILS with # Traceback (most recent call last): # File "bug.py", line 18, in ? # print new.instancemethod(n, None, B) # TypeError: instancemethod() argument 3 must be class, # not type def m(self): pass class B(object): def f(self): pass print new.instancemethod(n, None, B) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:21 Message: Logged In: YES user_id=6380 You're right. The new.instancemethod() call makes unnecessary typechecks. Fixed in CVS. Should be ported to 2.2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503091&group_id=5470 From noreply@sourceforge.net Tue Jan 15 19:24:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 11:24:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None >Priority: 5 Submitted By: Jason Cowley (sachmoz) >Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Tue Jan 15 19:33:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 11:33:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:33 Message: Logged In: YES user_id=6380 (1) I think subclassing SystemExit can work. (2) But the difference is that killing the main thread without giving it a chance to clean up is worse than killing another thread. Does anybody want to write a PEP on thread cancellation? It sure looks like a hairy issue! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-14 00:40 Message: Logged In: YES user_id=21627 On (1): This is quite unfortunate, as I do think sys.exit and thread.exit should do different things. There would be approaches of further subclassing SystemExit; preserving the property that raising SystemExit in a thread exits the thread only - would such a solution be acceptable? On (2): This is no different from raising SystemExit in the main thread, which also does not invoke finally clauses in other threads. I don't think there can be a complete, reliable implementation of thread cancellation, only a best-effort approach. For POSIX, I'd suggest sending SIGUSR2 to each thread through pthread_kill. We might need to add a mechanism indicating whether a thread is ready to be cancelled, similar to the POSIX cancellation points. That would prevent the signal from arriving in an arbitrary library function, and defer thread termination until the library function completes. For blocking system calls, sending signals would need to be activated explicitly, to allow aborting them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-12 12:03 Message: Logged In: YES user_id=6380 (1) It's too late to change the meaning of SystemExit -- people are relying on SystemExit exiting the thread only. (2) If we provide a way for a thread to exit the whole program, how will finally clauses in other threads (including the main thread) be executed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 17:05 Message: Logged In: YES user_id=21627 Tim, I'm not surprised that raising SystemExit in a thread fails to exit Python; the reason simply is that threadmodule.c:t_bootstrap choses to ignore PyExc_SystemExit, when it instead should invoke PyErr_PrintEx instead. The bug is obviously that exit_thread also raises SystemExit, when people apparently really want sys.exit and thread.exit to be two different things. So I think thread.exit should raise ThreadExit, and raising SystemExit in a thread should cause Py_Exit to be invoked (along with all other necessary cleanup). In short, 2.12 of threadmodule.c was wrong, IMO. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Tue Jan 15 19:40:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 11:40:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-502236 ] Need way to exit application Message-ID: Bugs item #502236, was opened at 2002-01-11 00:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: Need way to exit application Initial Comment: I may be missing something but there doesn't seem to be any easy, correct way to exit a Python application and shut down the interpreter. sys.exit() raises the SysExit exception in the current thread but other threads keep running, so the application doesn't stop. You can do something brutal like os.kill() your process, but then cleanup actions (finally clauses) don't get run. Or you can create some elaborate application-specific framework for propagating an exit flag from one thread to all the rest. That's incredibly lame. What's needed is a simple function (maybe sys.allexit) that raises SysExit in all the threads of the application (it might have to first stop all the threads using the GIL or something like that). I'm surprised there isn't already something like this, but there's been some c.l.py discussion about it and it really seems to not be there. Is there some problem with the idea? I don't see one but I can't be sure. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2002-01-15 11:40 Message: Logged In: YES user_id=72053 I don't feel qualified to write such a PEP. You guys are more on top of this than I am. Maybe there's no portable way to do asynchronous exceptions between threads. I don't know what happens if you hit ctrl-C when running a multi- threaded Linux program. I don't think ctrl-C even works in Windows--all you can really do is bring up the task manager and blow away the whole process. But I think asynchronous exceptions are worth having even if they're OS specific and only work on some systems. As for how a thread can exit the whole program, I thought Guido's first message (saying raise some asynchronous exception in all the threads) sounded fine, if it's feasible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:33 Message: Logged In: YES user_id=6380 (1) I think subclassing SystemExit can work. (2) But the difference is that killing the main thread without giving it a chance to clean up is worse than killing another thread. Does anybody want to write a PEP on thread cancellation? It sure looks like a hairy issue! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-14 00:40 Message: Logged In: YES user_id=21627 On (1): This is quite unfortunate, as I do think sys.exit and thread.exit should do different things. There would be approaches of further subclassing SystemExit; preserving the property that raising SystemExit in a thread exits the thread only - would such a solution be acceptable? On (2): This is no different from raising SystemExit in the main thread, which also does not invoke finally clauses in other threads. I don't think there can be a complete, reliable implementation of thread cancellation, only a best-effort approach. For POSIX, I'd suggest sending SIGUSR2 to each thread through pthread_kill. We might need to add a mechanism indicating whether a thread is ready to be cancelled, similar to the POSIX cancellation points. That would prevent the signal from arriving in an arbitrary library function, and defer thread termination until the library function completes. For blocking system calls, sending signals would need to be activated explicitly, to allow aborting them. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-12 12:03 Message: Logged In: YES user_id=6380 (1) It's too late to change the meaning of SystemExit -- people are relying on SystemExit exiting the thread only. (2) If we provide a way for a thread to exit the whole program, how will finally clauses in other threads (including the main thread) be executed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 17:05 Message: Logged In: YES user_id=21627 Tim, I'm not surprised that raising SystemExit in a thread fails to exit Python; the reason simply is that threadmodule.c:t_bootstrap choses to ignore PyExc_SystemExit, when it instead should invoke PyErr_PrintEx instead. The bug is obviously that exit_thread also raises SystemExit, when people apparently really want sys.exit and thread.exit to be two different things. So I think thread.exit should raise ThreadExit, and raising SystemExit in a thread should cause Py_Exit to be invoked (along with all other necessary cleanup). In short, 2.12 of threadmodule.c was wrong, IMO. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-11 13:16 Message: Logged In: YES user_id=31435 Martin, change your program to do sys.exit(1) inside func() on the first iteration (or raise SystemExit similarly), and whether you're on Windows or Linux you should find that while the func() thread goes away, the main program keeps on running. If you do os._exit(1) instead, on Windows the main program does go away, but Guido said it doesn't on Linux (which didn't surprise me, given Linux's conflation of threads with processes). See also the "Killing Threads" thread in Python-Dev from late May of 2001, which said all the same things. The only thing I may have learned since then is that supposedly the *C* exit() function terminates all threads on Linux, via an atexit handler installed by libc, and so _exit() on Linux doesn't terminate all threads because _exit () doesn't call atexit functions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-11 08:19 Message: Logged In: YES user_id=21627 Can you produce an example demonstrating the problem? Please see the attached thr.py. It terminates fine; I fail to see the problem. When SystemExit is raised, it will eventually invoke the C library's exit(). If that is not incredibly lame, it will terminate all threads. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 07:46 Message: Logged In: YES user_id=6380 I'm struggling with this in a threaded distributed app we're developing for Zope Corp, so I agree that something like this would be nice. I think for starters, there should be a way to raise an asynchronous exception in a specific thread; all threads is easy then. There are plenty of implementation problems with this, however: if a thread is blocked in I/O, there's no portable way to get it to bail out of that I/O operation. There are also plenty of application-level issues: if asynchronous exceptions are common, maybe it is necessary to provide a way to temporarily block such exceptions in order to provide safety in some situations. Etc., etc. So please spare us your surprise and help looking for a mechanism that can be implemented. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502236&group_id=5470 From noreply@sourceforge.net Tue Jan 15 20:07:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 12:07:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-15 12:07 Message: Logged In: YES user_id=11105 It seems sachmoz registry settings are valid for IE, I checked this by changing my own settings from ftp=192.168.0.15:3128;http=192.168.0.13:3128 to ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128 IE works either before or after this change. Here's the only article I found on MSDN showing an example: http://support.microsoft.com/default.aspx?scid=kb;EN- US;q164035 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Tue Jan 15 20:18:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 12:18:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 12:18 Message: Logged In: YES user_id=6380 Looks like this code block in getproxies_registry() is broken then: # Per-protocol settings for p in proxyServer.split(';'): protocol, address = p.split('=', 1) proxies[protocol] = '%s://%s' % (protocol, address) It should only add the :// prefix if one isn't already there. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:07 Message: Logged In: YES user_id=11105 It seems sachmoz registry settings are valid for IE, I checked this by changing my own settings from ftp=192.168.0.15:3128;http=192.168.0.13:3128 to ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128 IE works either before or after this change. Here's the only article I found on MSDN showing an example: http://support.microsoft.com/default.aspx?scid=kb;EN- US;q164035 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Tue Jan 15 20:58:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 12:58:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-15 12:58 Message: Logged In: YES user_id=11105 Isn't the correct setting for an ftp proxy "http://192.168.0.15:3128" instead of "ftp://192.168.0.15:3128". At least, in Python 2.1, only the former works for me. In Python 2.2 neither does, but maybe that's a different issue. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 12:18 Message: Logged In: YES user_id=6380 Looks like this code block in getproxies_registry() is broken then: # Per-protocol settings for p in proxyServer.split(';'): protocol, address = p.split('=', 1) proxies[protocol] = '%s://%s' % (protocol, address) It should only add the :// prefix if one isn't already there. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:07 Message: Logged In: YES user_id=11105 It seems sachmoz registry settings are valid for IE, I checked this by changing my own settings from ftp=192.168.0.15:3128;http=192.168.0.13:3128 to ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128 IE works either before or after this change. Here's the only article I found on MSDN showing an example: http://support.microsoft.com/default.aspx?scid=kb;EN- US;q164035 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Tue Jan 15 21:07:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 13:07:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-503837 ] type.__module__ problems (again?) Message-ID: Bugs item #503837, was opened at 2002-01-15 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Guido van Rossum (gvanrossum) Summary: type.__module__ problems (again?) Initial Comment: Gelukkig nieuwjaar, This is probably related to previous bug reports on type.__module__. Given --- A.py --- class meta1(type): def __new__(tp, name, bases, attr): return type.__new__(tp, name, bases, attr) class meta2(type): pass --- B.py --- import A class B1(object): __metaclass__ = A.meta1 class B2(object): __metaclass__ = A.meta2 ------------ I get the following session. Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import B >>> B.B1.__module__ 'A' >>> B.B2.__module__ 'B' Among others, this problem causes pydoc to only display documentation for B2 as part of the docs for module B. Presumably, the behaviour for B2 is correct. Regards, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 13:07 Message: Logged In: YES user_id=6380 Fixed in compile.c 2.235, by initializing __module__ to the contents of the global variable __name__ at the start of the class statement. Not 100% satisfied with that, but can't come up with something better right now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:33 Message: Logged In: YES user_id=6380 You're right. This is because __module__ is taken from the globals of the currently executing Python code. This is clearly a bug. I'll have to think about how to fix it -- maybe the class statement will have to set it. I can't find the other bug reports related to __module__; the SF search box apparently searches for "module" when I type that in the search box, and that hits about every other bug report ever submitted, including closed ones. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 From noreply@sourceforge.net Tue Jan 15 23:03:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 15:03:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-503570 ] Python 2.1.2c1 missing a bugfix Message-ID: Bugs item #503570, was opened at 2002-01-14 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503570&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Shane Hathaway (hathawsh) >Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1.2c1 missing a bugfix Initial Comment: There was a change made recently to importdl.c to correct a bug that happens when extensions defined in a package try to import another extension. The bugfix is not in Python 2.1.2c1. See patch #471839. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 15:03 Message: Logged In: YES user_id=6380 Thanks for the reminder. I've added it to 2.1.2 at the last minute. Keep your fingers crossed! :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503570&group_id=5470 From noreply@sourceforge.net Wed Jan 16 01:31:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 17:31:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-15 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply@sourceforge.net Wed Jan 16 02:47:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 18:47:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-15 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 18:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply@sourceforge.net Wed Jan 16 04:56:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 20:56:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-504219 ] locale.setlocale is broken Message-ID: Bugs item #504219, was opened at 2002-01-15 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Syver Enstad (syvere) Assigned to: Tim Peters (tim_one) Summary: locale.setlocale is broken Initial Comment: locale.setlocale doesn't recognize the the format that locale.py uses to set the locale, ie. no_NO and friends. The only way I've succeeded in setting the locale on Python 2.1 is to use the format described in the Visual C++ C-runtime library docs for setlocale where a more verbose format is used to set the locale. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 From noreply@sourceforge.net Wed Jan 16 05:07:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 21:07:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-504219 ] locale.setlocale is broken Message-ID: Bugs item #504219, was opened at 2002-01-15 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Syver Enstad (syvere) >Assigned to: Mark Hammond (mhammond) Summary: locale.setlocale is broken Initial Comment: locale.setlocale doesn't recognize the the format that locale.py uses to set the locale, ie. no_NO and friends. The only way I've succeeded in setting the locale on Python 2.1 is to use the format described in the Visual C++ C-runtime library docs for setlocale where a more verbose format is used to set the locale. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-15 21:07 Message: Logged In: YES user_id=31435 Mark, know anything about this? I don't. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 From noreply@sourceforge.net Wed Jan 16 07:28:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 23:28:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-477487 ] Build Problems on AIX 4.3.3 Message-ID: Bugs item #477487, was opened at 2001-11-02 03:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Build Problems on AIX 4.3.3 Initial Comment: Problems in building Python 2.2b1 in AIX 4.3.3 with IBM vac++ compiler. I think the problem is not compiler specific. The build tries to execute the following code: ../Modules/makexp_aix Modules/python.exp "" libpython2.2.a; -Wl,-bE:Modules/python.exp -lld -o python \ Modules/ccpython.o \ libpython2.2.a -ldl -lpthread -lm The first part executes ok: ../Modules/makexp_aix Modules/python.exp "" libpython2.2.a In the second part the call to the linker is missing. Something like : xlC_r -Wl,-bE:Modules/python.exp -lld -o python Modules/ccpython.o libpython2.2.a -ldl -lpthread -lm dose the job ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-15 23:28 Message: Logged In: YES user_id=418821 Sorry if I wasn't clear, please change this line: LINKCC="\/Modules/makexp_aix Modules/python.exp \\ \; $(LINKCC)";; to LINKCC="\/Modules/makexp_aix Modules/python.exp \\ \; $LINKCC";; ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:38 Message: Logged In: YES user_id=6380 srubben: I don't understand your suggestion. What brackets? Can you type in the correct line? ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-15 01:57 Message: Logged In: YES user_id=418821 The following lines in the configure script (the check for LINKCC) should be changed: case $ac_sys_system in AIX*) LINKCC="\/Modules/makexp_aix Modules/python.exp \\ \; $(LINKCC)";; The brackets around the $(LINKCC) should be removed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=477487&group_id=5470 From noreply@sourceforge.net Wed Jan 16 08:01:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 00:01:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-504252 ] More build problems on AIX 4.3 Message-ID: Bugs item #504252, was opened at 2002-01-16 00:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 From noreply@sourceforge.net Wed Jan 16 08:16:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 00:16:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-503837 ] type.__module__ problems (again?) Message-ID: Bugs item #503837, was opened at 2002-01-15 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Roeland Rengelink (rengelink) Assigned to: Guido van Rossum (gvanrossum) Summary: type.__module__ problems (again?) Initial Comment: Gelukkig nieuwjaar, This is probably related to previous bug reports on type.__module__. Given --- A.py --- class meta1(type): def __new__(tp, name, bases, attr): return type.__new__(tp, name, bases, attr) class meta2(type): pass --- B.py --- import A class B1(object): __metaclass__ = A.meta1 class B2(object): __metaclass__ = A.meta2 ------------ I get the following session. Python 2.2 (#4, Jan 7 2002, 11:59:25) [GCC 2.95.2 19991024 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import B >>> B.B1.__module__ 'A' >>> B.B2.__module__ 'B' Among others, this problem causes pydoc to only display documentation for B2 as part of the docs for module B. Presumably, the behaviour for B2 is correct. Regards, Roeland Rengelink ---------------------------------------------------------------------- >Comment By: Roeland Rengelink (rengelink) Date: 2002-01-16 00:16 Message: Logged In: YES user_id=302601 I came upon the other bug reports by browsing the bug database, but I didn't write the numbers down. The only ones I did find again when I looked this morning are: #442501 #487390 Neither are really related to the problem reported here though, Thanks for the fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 13:07 Message: Logged In: YES user_id=6380 Fixed in compile.c 2.235, by initializing __module__ to the contents of the global variable __name__ at the start of the class statement. Not 100% satisfied with that, but can't come up with something better right now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:33 Message: Logged In: YES user_id=6380 You're right. This is because __module__ is taken from the globals of the currently executing Python code. This is clearly a bug. I'll have to think about how to fix it -- maybe the class statement will have to set it. I can't find the other bug reports related to __module__; the SF search box apparently searches for "module" when I type that in the search box, and that hits about every other bug report ever submitted, including closed ones. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470 From noreply@sourceforge.net Wed Jan 16 08:21:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 00:21:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-504259 ] More build problems on AIX 4.3 Message-ID: Bugs item #504259, was opened at 2002-01-16 00:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504259&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504259&group_id=5470 From noreply@sourceforge.net Wed Jan 16 08:29:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 00:29:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-504259 ] More build problems on AIX 4.3 Message-ID: Bugs item #504259, was opened at 2002-01-16 00:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504259&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- >Comment By: Sven Rubben (srubben) Date: 2002-01-16 00:29 Message: Logged In: YES user_id=418821 Sorry about this one, network problems and I was stupid enough to click submit again.... :-( This is a duplicate of 504252. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504259&group_id=5470 From noreply@sourceforge.net Wed Jan 16 09:48:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 01:48:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-504282 ] python 2.2 shelve Message-ID: Bugs item #504282, was opened at 2002-01-16 01:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504282&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib und Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504282&group_id=5470 From noreply@sourceforge.net Wed Jan 16 09:50:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 01:50:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 10:04:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 02:04:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-504291 ] python 2.2 shelve Message-ID: Bugs item #504291, was opened at 2002-01-16 02:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504291&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib under Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504291&group_id=5470 From noreply@sourceforge.net Wed Jan 16 10:24:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 02:24:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-504300 ] python 2.2 shelve Message-ID: Bugs item #504300, was opened at 2002-01-16 02:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504300&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib under Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504300&group_id=5470 From noreply@sourceforge.net Wed Jan 16 10:34:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 02:34:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-504305 ] python 2.2 shelve Message-ID: Bugs item #504305, was opened at 2002-01-16 02:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504305&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib under Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504305&group_id=5470 From noreply@sourceforge.net Wed Jan 16 11:50:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 03:50:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-504219 ] locale.setlocale is broken Message-ID: Bugs item #504219, was opened at 2002-01-15 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Syver Enstad (syvere) Assigned to: Mark Hammond (mhammond) Summary: locale.setlocale is broken Initial Comment: locale.setlocale doesn't recognize the the format that locale.py uses to set the locale, ie. no_NO and friends. The only way I've succeeded in setting the locale on Python 2.1 is to use the format described in the Visual C++ C-runtime library docs for setlocale where a more verbose format is used to set the locale. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 03:50 Message: Logged In: YES user_id=21627 Can you provide a detailed test case? AFAIK, no_NO is indeed no supported locale name on Windows, and I don't think Python aanywhere uses it without the application explicitly saying so. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-15 21:07 Message: Logged In: YES user_id=31435 Mark, know anything about this? I don't. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 From noreply@sourceforge.net Wed Jan 16 11:51:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 03:51:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-504291 ] python 2.2 shelve Message-ID: Bugs item #504291, was opened at 2002-01-16 02:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504291&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib under Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 03:51 Message: Logged In: YES user_id=21627 Duplicate of #504282. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504291&group_id=5470 From noreply@sourceforge.net Wed Jan 16 11:52:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 03:52:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-504300 ] python 2.2 shelve Message-ID: Bugs item #504300, was opened at 2002-01-16 02:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504300&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib under Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 03:52 Message: Logged In: YES user_id=21627 Duplicate of #504282. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504300&group_id=5470 From noreply@sourceforge.net Wed Jan 16 11:52:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 03:52:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-504305 ] python 2.2 shelve Message-ID: Bugs item #504305, was opened at 2002-01-16 02:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504305&group_id=5470 Category: Extension Modules Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib under Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 03:52 Message: Logged In: YES user_id=21627 Duplicate of #504282. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504305&group_id=5470 From noreply@sourceforge.net Wed Jan 16 11:54:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 03:54:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-504259 ] More build problems on AIX 4.3 Message-ID: Bugs item #504259, was opened at 2002-01-16 00:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504259&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 00:29 Message: Logged In: YES user_id=418821 Sorry about this one, network problems and I was stupid enough to click submit again.... :-( This is a duplicate of 504252. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504259&group_id=5470 From noreply@sourceforge.net Wed Jan 16 12:02:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 04:02:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-504252 ] More build problems on AIX 4.3 Message-ID: Bugs item #504252, was opened at 2002-01-16 00:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:02 Message: Logged In: YES user_id=21627 I think the problem is somewhere else: When building Python itself, BLDSHARED should be used. LDSHARED will be appropriate when building extension modules with distutils, so it must point to the installed ld_so_aix, not the one in the source distribution. So in essence, you will need to replace LDSHARED with BLDSHARED in the appropriate places of Makefile.in. Can you place try to come up with a patch that does so, and attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 From noreply@sourceforge.net Wed Jan 16 12:07:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 04:07:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-504282 ] python 2.2 shelve Message-ID: Bugs item #504282, was opened at 2002-01-16 01:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504282&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: tarski (tarski9) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.2 shelve Initial Comment: I've created a shelve 'db-test' under Red Hat Linux 7.1 and Python 2.1.1. When I want to open this shelve under Win2k with Python 2.1.1 or Python 2.2, following occurs. >>> db = shelve.open("C:\db-test") Traceback (most recent call last): File "", line 1, in ? db = shelve.open("C:\db-test") File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 158, in open return DbfilenameShelf(filename, flag) File "C:\PROGRAMS\PYTHON22\lib\shelve.py", line 148, in __init__ Shelf.__init__(self, anydbm.open(filename, flag)) File "C:\PROGRAMS\PYTHON22\lib\anydbm.py", line 86, in open return mod.open(file, flag, mode) File "C:\PROGRAMS\PYTHON22\lib\dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') Is there a bug in the bsddb.lib und Windows? Is there a solution to create shelves under Linux and to use them under Windows? Thanks tarski ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:07 Message: Logged In: YES user_id=21627 Unfortunately, there are different versions of BSDDB in circulation, which use different file formats. On Linux, please do ldd /lib-dynload/bsddbmodule.so to find out what version you have linked with. Also, please invoke file(1) to find out the file version. I can't tell off-hand what version the standard Windows installation is build with, but knowing what you use on Linux will get us closer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504282&group_id=5470 From noreply@sourceforge.net Wed Jan 16 12:10:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 04:10:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Wed Jan 16 12:12:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 04:12:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-15 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2002-01-16 04:12 Message: Logged In: YES user_id=6405 Yes, we had someone submit a bug report on the roundup users mailing list because someone had sent a message to the roundup mail gateway which was split. The client was extra-specially broken, since it split in the middle of a word (which is not to spec), but the more general case of folding on whitespace will cause roundup problems since I hadn't expected there to be any newlines in the header. I can modify roundup to strip out the newline, but it'd be nice to have rfc822.Message not put it in there... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 18:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply@sourceforge.net Wed Jan 16 12:14:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 04:14:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-15 17:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:14 Message: Logged In: YES user_id=21627 Even though it might not matter, I don't think changing it would hurt, either, and the change brings it definitely closer to following the word of RFC 2822. If no case is brought forward where it matters, fixing it for 2.3 alone should be sufficient. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2002-01-16 04:12 Message: Logged In: YES user_id=6405 Yes, we had someone submit a bug report on the roundup users mailing list because someone had sent a message to the roundup mail gateway which was split. The client was extra-specially broken, since it split in the middle of a word (which is not to spec), but the more general case of folding on whitespace will cause roundup problems since I hadn't expected there to be any newlines in the header. I can modify roundup to strip out the newline, but it'd be nice to have rfc822.Message not put it in there... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 18:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply@sourceforge.net Wed Jan 16 12:18:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 04:18:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Wed Jan 16 13:03:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 05:03:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Wed Jan 16 13:03:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 05:03:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=11105 Here's a quote from Microsoft docs (Windows 2000 Server Resource Kit). I have not found it online, but it's in my local MSDN library April 2001: MSDNLibrary -> Resource Kits -> Windows 2000 Server Resource Kit -> Internet Explorer 5 Resource Kit -> Part 3: Customizing -> Chapter 13: Setting up Servers -> Working with Proxy Servers Proxy locations that do not begin with a protocol (such as http:// or ftp://) are assumed to be a CERN-type HTTP proxy. For example, when the user types proxy, it's treated the same as if the user typed http://proxy. For FTP gateways, such as the TIS FTP gateway, the proxy should be listed with the ftp:// in front of the proxy name. For example, an FTP gateway for an FTP proxy would have this format: ftp://ftpproxy When you enter proxy settings, use the following syntax, where
is the Web address of the proxy server and is the port number assigned to the proxy server: http://
: For example, if the address of the proxy server is proxy.example.microsoft.com and the port number is 80, the setting in the Proxy Server box for LAN settings in the Proxy Settings dialog box or the Proxy Settings screen of the Customization wizard should read as follows: http://proxy.example.microsoft.com:80 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:58 Message: Logged In: YES user_id=11105 Isn't the correct setting for an ftp proxy "http://192.168.0.15:3128" instead of "ftp://192.168.0.15:3128". At least, in Python 2.1, only the former works for me. In Python 2.2 neither does, but maybe that's a different issue. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 12:18 Message: Logged In: YES user_id=6380 Looks like this code block in getproxies_registry() is broken then: # Per-protocol settings for p in proxyServer.split(';'): protocol, address = p.split('=', 1) proxies[protocol] = '%s://%s' % (protocol, address) It should only add the :// prefix if one isn't already there. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:07 Message: Logged In: YES user_id=11105 It seems sachmoz registry settings are valid for IE, I checked this by changing my own settings from ftp=192.168.0.15:3128;http=192.168.0.13:3128 to ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128 IE works either before or after this change. Here's the only article I found on MSDN showing an example: http://support.microsoft.com/default.aspx?scid=kb;EN- US;q164035 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Wed Jan 16 13:34:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 05:34:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-16 05:34 Message: Logged In: YES user_id=6656 Argh! At least this should be easy to fix. What's a good preprocessor symbol for AIX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 13:39:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 05:39:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-504219 ] locale.setlocale is broken Message-ID: Bugs item #504219, was opened at 2002-01-15 20:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Syver Enstad (syvere) Assigned to: Mark Hammond (mhammond) Summary: locale.setlocale is broken Initial Comment: locale.setlocale doesn't recognize the the format that locale.py uses to set the locale, ie. no_NO and friends. The only way I've succeeded in setting the locale on Python 2.1 is to use the format described in the Visual C++ C-runtime library docs for setlocale where a more verbose format is used to set the locale. ---------------------------------------------------------------------- >Comment By: Syver Enstad (syvere) Date: 2002-01-16 05:39 Message: Logged In: YES user_id=428736 Sorry, I forgot to mention the testcase I am using. The test case that fails is the locale module itself, when running it as a standalone application that is. To be more specific: File "d:\devtools\python21\lib\locale.py", line 384, in resetlocale _setlocale(category, _build_localename(getdefaultlocale ())) locale.Error: locale setting not supported And to clarify what input getdefaultlocale returns on my machine: >>> locale.getdefaultlocale() ('no_NO', 'cp1252') and: >>> locale._build_localename(locale.getdefaultlocale()) 'no_NO.cp1252' By the way, is this bug fixed in python 2.2? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 03:50 Message: Logged In: YES user_id=21627 Can you provide a detailed test case? AFAIK, no_NO is indeed no supported locale name on Windows, and I don't think Python aanywhere uses it without the application explicitly saying so. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-15 21:07 Message: Logged In: YES user_id=31435 Mark, know anything about this? I don't. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504219&group_id=5470 From noreply@sourceforge.net Wed Jan 16 14:28:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 06:28:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700 Message-ID: Bugs item #425007, was opened at 2001-05-17 16:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Michael Hudson (mwh) Summary: Python 2.1 installs shared libs with mode 0700 Initial Comment: I have gone back and tried Python 1.6 and 2.0. Both work fine. When I install Python 2.1, everything is broken. The problem is that when a module is a shared library (.so), python refuses to load the module. Example: import os import sys import SocketServer Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/SocketServer.py", line 126, in ? import socket File "/usr/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Now, do a "locate _socket.so" and I get: /usr/lib/python2.1/site-packages/_socket.so /usr/lib/python2.1/lib-dynload/_socket.so Clearly they are there, it's just that Python refuses to load them. I made Python 2.1 from source as fetched from the 2.1 tar ball. It makes cleanly. During the installation, I see some items that I believe to be minor that popup, but don't currectly expect that they are the problem. I have tried many times using different configure options to get this to work, deleting the previous installation each time. I've even tried installing in different locations. As is, Python 2.1 is completely broken for me. Surely I'm not the only one having this problem, especially since 1.5, 1.6, and 2.0 all work correctly. Any help would be great. BTW, doing a "print sys.path" gives me: ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/lib/python2.1/site-packages'] As you can see, lib-dynload is in the path, so I'm not really sure what's going on. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-16 06:28 Message: Logged In: YES user_id=6656 I'll do something about this at some point. Using copy_tree to install shared libraries is gross. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-21 23:24 Message: Logged In: YES user_id=149084 INSTALLATION: Confirm. Built with umask 077, group and others have no permissions in source tree. (Note that if I su to install, the 077 follows! ok, install with umask of 022, normal for root.). Everything in installation looks ok except for lib-dynload, which has 700 permissions on files. No _socket.so in site-packages. REINSTALLATION: I suspect there is more to this than distutils...Redo the build with umask 022. Then chmod the whole previously installed tree to 700 and if you then repeat the install on top of it you find that while the .py files have been correctly copied by /usr/bin/install with 644, the .pyc and .pyo are still 700 though recompiled. This also happens in 1.5.2. The lib-dynload files are 755. This is with a umask of 022 for both the build user and root. Finally, delete a few files from lib-dynload, chmod the rest to 700, and make install again! The deleted files are restored at 755, the rest stay at 700. In general, messed up permissions are not fixed by a re-install. It would seem desirable that re-installing should result in exactly the same install tree as the initial install, including permissions, except that any non-distribution files (e.g. "site-packages") added by the user would be unaffected. If the user had modified some distribution .py files they would be reverted by the re-install, which does seem to be the case. A broken installation could be repaired by re-installing. Would that be a reasonable policy? Or is it too difficult to fix up all the permissions? A compromise might be to delete the .pyo .pyc before compiling, and explicitly chmod all the lib-dynload files during install. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 13:15 Message: Logged In: YES user_id=11375 Reclassifying as a Distutils bug. The install_lib subcommand simply copies the contents of the BUILD/ tree. It needs to pointedly ignore the umask and set the proper permissions on the installed files. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 12:32 Message: Logged In: YES user_id=6380 Assigning this to Andrew -- clearly the setup.py script (or distutils) needs to be fixed to fix this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 12:24 Message: Logged In: YES user_id=6380 I didn't mean to imply that you did something incorrectly. I just meant that there was some interaction between your system and Python that didn't work out the way it was supposed to be. Since Python installs correctly on most systems, I was implying that there's something unusual in your system that the Python install procedure doesn't anticipate. The mode 0700 for the shared libraries is a big hint at what was wrong (and if you had done an ls -l of the file when first reporting this we would have figured out the problem much quicker). Is perhaps the umask of the user who built (not installed) the files set to 077? In that case, the cause is that the "make install" by root doesn't change the file modes to something more reasonable (I've confirmed that this indeed happens). I'll look into whether this can be fixed. I'm changing the subject line of this bug report to reflect more accurately that the problem is with the file modes of shared libs. I still believe that the _socket.so in site-packages could not have been placed there by the normal Python install procedure. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2001-05-21 08:13 Message: Logged In: YES user_id=40173 The problem is that the installation is partially broken. It didn't install the shared libraries with proper permissions. When Python installed the shared libs, it installed the libs as root.root having 0700 permissions. When I tried to execute it as a normal user, obviously, it fails to load the shared lib. Python then, incorrectly reports that the shared lib can not be found. Of course, the correct solution is for Python to accurately report the problem and to have the installation always install the libraries with correct ownership and permission. I don't think I'm asking for too much here. Seems pretty reasonable to me. Anyone stating that I did not install correctly is woefully incorrect. Simply put, the installation is not 100%. As for some of the libraries existing twice. Well, simply put, the installation is not 100%. At any rate, I think it's safe to close this bug but we might want to add it to the faq-o-matic somewhere or some such thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-20 10:35 Message: Logged In: YES user_id=6380 Clearly it's something you have done to yourself. :-) The question is how to find out what. Try "python -v" or even "python -vv" and see what it prints when you try to import _socket. This should give you some clues (it shows where it searches for modules during import). As kbk says, that other _socket.so is mysterious. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-19 17:16 Message: Logged In: YES user_id=149084 Well, import SocketServer works ok for me with Python built both from the 2.1 tar file and the 2.2a0 CVS tree. I'm running Linux 2.2.5 (RH 6.2) on Pentium. Did you make clean after changing the configure options? It is not normal to have _socket.so in .../site-packages; it should be only in .../lib-dynload. Default installation has only the README file in site-packages. Your sys.path looks normal, except that Python default installs at /usr/local/[bin/lib]. I tried a build targeted at /usr/[bin/lib] and it was ok. You could try make clobber, but it's almost as fast to start over. Try a vanilla installation: 1. delete your install tree @ /usr/local/lib/python2.1 (and/or /usr/lib) 2. delete your source tree from wherever you unpacked the tar file. 3. untar again, cd to source directory it created 4. without changing any files, and no configure options, run ./configure, then make, then make install If that doesn't help, what Linux are you running, on what box, and where did you get your 2.1 tar file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 From noreply@sourceforge.net Wed Jan 16 14:45:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 06:45:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- >Comment By: Sven Rubben (srubben) Date: 2002-01-16 06:45 Message: Logged In: YES user_id=418821 I think _AIX should do the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 05:34 Message: Logged In: YES user_id=6656 Argh! At least this should be easy to fix. What's a good preprocessor symbol for AIX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:15:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:15:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sven Rubben (srubben) >Assigned to: Michael Hudson (mwh) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-16 07:15 Message: Logged In: YES user_id=6656 Right, I think that's fixed in revision 2.62 of _cursesmodule.c. Is it easy for you to check current CVS? ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 06:45 Message: Logged In: YES user_id=418821 I think _AIX should do the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 05:34 Message: Logged In: YES user_id=6656 Argh! At least this should be easy to fix. What's a good preprocessor symbol for AIX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:25:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:25:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-434944 ] setup.py - nonstandard paths Message-ID: Bugs item #434944, was opened at 2001-06-20 15:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 Category: Build Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) >Assigned to: Michael Hudson (mwh) Summary: setup.py - nonstandard paths Initial Comment: In my build environment I have to ensure that the same version of each software package is available across many different platforms. To do this I compile code into a directory structure when the root path of /usr/tools/fw. So a tools like flex would result in files /usr/tools/fw/bin/flex, /usr/tools/fw/include/FlexLexer.h, /usr/tools/fw/lib/libfl.a, ... In the Python 2.1 build environment it does not seem that you can pass extra search paths too setup.py. I must either hack setup.py to look in /usr/tools/fw or manually add each module to Modules/Setup. It would be nice for setup.py to be able to take extra search paths. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-16 07:23 Message: Logged In: YES user_id=6656 Hello? I'm going to close this in a week if there's no further response. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:19 Message: Logged In: YES user_id=6656 Don't the -I & -L options to setup.py handle this? As in: ./python $(srcdir)/setup.py -I/usr/tools/fw/include \ -L/usr/tools/fw/lib ? I can't see how to arrange things to do this just by typing "make" -- is that what you're complaining about? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:36:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:36:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Michael Hudson (mwh) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- >Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:36 Message: Logged In: YES user_id=418821 I've checked version 2.63, and it is ok. ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:36 Message: Logged In: YES user_id=418821 I've checked versio 2.63, and it is ok. Thanks! ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:36 Message: Logged In: YES user_id=418821 I've checked versio 2.63, and it is ok. Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 07:15 Message: Logged In: YES user_id=6656 Right, I think that's fixed in revision 2.62 of _cursesmodule.c. Is it easy for you to check current CVS? ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 06:45 Message: Logged In: YES user_id=418821 I think _AIX should do the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 05:34 Message: Logged In: YES user_id=6656 Argh! At least this should be easy to fix. What's a good preprocessor symbol for AIX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:36:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:36:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Michael Hudson (mwh) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- >Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:36 Message: Logged In: YES user_id=418821 I've checked versio 2.63, and it is ok. Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 07:15 Message: Logged In: YES user_id=6656 Right, I think that's fixed in revision 2.62 of _cursesmodule.c. Is it easy for you to check current CVS? ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 06:45 Message: Logged In: YES user_id=418821 I think _AIX should do the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 05:34 Message: Logged In: YES user_id=6656 Argh! At least this should be easy to fix. What's a good preprocessor symbol for AIX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:36:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:36:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-504284 ] Last build problems on AIX Message-ID: Bugs item #504284, was opened at 2002-01-16 01:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 Category: Build Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Michael Hudson (mwh) Summary: Last build problems on AIX Initial Comment: Compilation fails with an error indicating that tparm is called with too few parameters in the file _cursesmodule.c The file _cursesmodule.c calls tparm() with a define to check if it is HPUX or not. The reason is that tparm can be either defined with 10 arguments or with a variable number of parameters. On AIX you have both, but the standard is the one with 10 parameters. If you want the variable number of parameters you have to define _TPARM_COMPAT. So there are two solutions (look in _cursesmodule.c, function PyCurses_tparm): 1) Change the ifdef around the tparm with 10 arguments to also include AIX (you can use _AIX for this). 2) Define _TPARM_COMPAT if we are running on AIX. ---------------------------------------------------------------------- >Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:36 Message: Logged In: YES user_id=418821 I've checked versio 2.63, and it is ok. Thanks! ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:36 Message: Logged In: YES user_id=418821 I've checked versio 2.63, and it is ok. Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 07:15 Message: Logged In: YES user_id=6656 Right, I think that's fixed in revision 2.62 of _cursesmodule.c. Is it easy for you to check current CVS? ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 06:45 Message: Logged In: YES user_id=418821 I think _AIX should do the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 05:34 Message: Logged In: YES user_id=6656 Argh! At least this should be easy to fix. What's a good preprocessor symbol for AIX? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504284&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:37:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:37:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Jason Cowley (sachmoz) Date: 2002-01-16 07:37 Message: Logged In: YES user_id=426262 I have found the document that theller referred to online, the URL is: http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk /Ch13_d.htm or alternatively: http://www.microsoft.com/windows2000/techinfo/reskit/en- us/default.asp?url=/WINDOWS2000/techinfo/reskit/en- us/ierk/Ch13_d.asp The actual registry entries that I posted earlier appear to be set by Windows2000/IE6. If you make the following series of clicks from IE: Tools | Internet Options | Connections Then in the section: Dial-up and Virtual Private Network settings click the Settings... button, then the Advanced... button under Proxy server, you will see a list of proxy servers for different protocols. If I add a fake proxy server for Gopher, such as: http://www-cache.sachmoz.com with port 8080, the registry key data is altered to: ftp=http://www-cache.freeserve.com:8080;gopher=http://www- cache.sachmoz.com:8080;http=http://www- cache.freeserve.com:8080 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=11105 Here's a quote from Microsoft docs (Windows 2000 Server Resource Kit). I have not found it online, but it's in my local MSDN library April 2001: MSDNLibrary -> Resource Kits -> Windows 2000 Server Resource Kit -> Internet Explorer 5 Resource Kit -> Part 3: Customizing -> Chapter 13: Setting up Servers -> Working with Proxy Servers Proxy locations that do not begin with a protocol (such as http:// or ftp://) are assumed to be a CERN-type HTTP proxy. For example, when the user types proxy, it's treated the same as if the user typed http://proxy. For FTP gateways, such as the TIS FTP gateway, the proxy should be listed with the ftp:// in front of the proxy name. For example, an FTP gateway for an FTP proxy would have this format: ftp://ftpproxy When you enter proxy settings, use the following syntax, where
is the Web address of the proxy server and is the port number assigned to the proxy server: http://
: For example, if the address of the proxy server is proxy.example.microsoft.com and the port number is 80, the setting in the Proxy Server box for LAN settings in the Proxy Settings dialog box or the Proxy Settings screen of the Customization wizard should read as follows: http://proxy.example.microsoft.com:80 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:58 Message: Logged In: YES user_id=11105 Isn't the correct setting for an ftp proxy "http://192.168.0.15:3128" instead of "ftp://192.168.0.15:3128". At least, in Python 2.1, only the former works for me. In Python 2.2 neither does, but maybe that's a different issue. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 12:18 Message: Logged In: YES user_id=6380 Looks like this code block in getproxies_registry() is broken then: # Per-protocol settings for p in proxyServer.split(';'): protocol, address = p.split('=', 1) proxies[protocol] = '%s://%s' % (protocol, address) It should only add the :// prefix if one isn't already there. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:07 Message: Logged In: YES user_id=11105 It seems sachmoz registry settings are valid for IE, I checked this by changing my own settings from ftp=192.168.0.15:3128;http=192.168.0.13:3128 to ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128 IE works either before or after this change. Here's the only article I found on MSDN showing an example: http://support.microsoft.com/default.aspx?scid=kb;EN- US;q164035 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Wed Jan 16 15:43:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 07:43:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-504252 ] More build problems on AIX 4.3 Message-ID: Bugs item #504252, was opened at 2002-01-16 00:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- >Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:43 Message: Logged In: YES user_id=418821 Ok, I think I understand now. I should read the scripts more carefully before submitting such a comment. Does the attached diff solve it in the correct way? It builds cleanly now with this one. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:02 Message: Logged In: YES user_id=21627 I think the problem is somewhere else: When building Python itself, BLDSHARED should be used. LDSHARED will be appropriate when building extension modules with distutils, so it must point to the installed ld_so_aix, not the one in the source distribution. So in essence, you will need to replace LDSHARED with BLDSHARED in the appropriate places of Makefile.in. Can you place try to come up with a patch that does so, and attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 From noreply@sourceforge.net Wed Jan 16 16:44:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 08:44:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-501164 ] 2.2 on linux SEGV sometimes Message-ID: Bugs item #501164, was opened at 2002-01-08 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: MATSUI Tetsushi (tetsushi) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 on linux SEGV sometimes Initial Comment: I am using Python 2.2. The execution with pure python scripts suddenly stops after several hours or a few days. With the latest core I run gdb, it says: Program terminated with signal 11, Segmentation fault. and the head of bt is like this: #0 0x80afb1e in binary_op1 (v=0x8dc0f54, w=0x8c641bc, op_slot=4) at Objects/abstract.c:340 #1 0x80b2537 in PyNumber_Subtract (v=0x8dc0f54, w=0x8c641bc) at Objects/abstract.c:392 #2 0x8079f27 in eval_frame (f=0x820c1fc) at Python/ceval.c:988 #3 0x807cd50 in PyEval_EvalCodeEx (co=0x81cf608, globals=0x81d5214, locals=0x0, args=0x8202fc4, argcount=5, kws=0x8202fd8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2574 #4 0x807f41c in fast_function (func=0x81e4584, pp_stack=0xbfffe474, n=5, na=5, nk=0) at Python/ceval.c:3150 Thanks, tetsushi ---------------------------------------------------------------------- >Comment By: MATSUI Tetsushi (tetsushi) Date: 2002-01-16 08:44 Message: Logged In: YES user_id=421269 I tried to reproduce SEGV. from alib import * for i in range(10000,50000): n=(i**7-1)/(i-1) if isprime(n): continue print n,MPQS(n).run() The above script stopped when i was 17359. It took about 1 day on my PC. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-14 14:21 Message: Logged In: YES user_id=21627 I cannot reproduce this: >>> from alib import * >>> MPQS(30).run() starting MPQS 10 {10: 1, 3: 1}>>> MPQS(3000000000000000000000000000000000).run() starting MPQS 1000000000000000000000000000000000 {1000000000000000000000000000000000L: 1, 3: 1} Can you please give the *precise* sequence of commands to make this crash? ---------------------------------------------------------------------- Comment By: MATSUI Tetsushi (tetsushi) Date: 2002-01-08 23:00 Message: Logged In: YES user_id=421269 OK, I attach the main script. (Maybe the 1659-th line is the stopping point.) It consists of many factoring or primality testing functions and classes, and the stopping point I suspect is in the class MPQS. To run the algorithm MPQS(n).run() where n is about 30 decimal digit composite. The length of stack trace is 53. The last 3 are like this: #50 0x8053fcb in Py_Main (argc=5, argv=0xbffff644) at Modules/main.c:369 #51 0x8053a47 in main (argc=5, argv=0xbffff644) at Modules/python.c:10 #52 0x4004ca49 in Letext () Thanks, tetsushi. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-08 20:00 Message: Logged In: YES user_id=6380 Can you attach the script, any input data it needs, and instructions for running it? Otherwise there's no hope in debugging this. Also, how long is the stack? Could it be a stack overflow? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501164&group_id=5470 From noreply@sourceforge.net Wed Jan 16 17:31:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 09:31:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem Message-ID: Bugs item #503031, was opened at 2002-01-13 10:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason Cowley (sachmoz) Assigned to: Mark Hammond (mhammond) Summary: urllib.py: open_http() host problem Initial Comment: While trying to use the httplib.py urlopen() function, as follows: doc = urlopen("http://www.python.org").read() print doc I was receiving the following trace: Traceback (most recent call last): File "C:/Documents and Settings/Administrator/Desktop/jason/grabpage.py", line 3, in ? doc = urlopen("http://www.python.org").read() File "C:\Python22\lib\urllib.py", line 73, in urlopen return _urlopener.open(url) File "C:\Python22\lib\urllib.py", line 178, in open return getattr(self, name)(url) File "C:\Python22\lib\urllib.py", line 283, in open_http h = httplib.HTTP(host) File "C:\Python22\lib\httplib.py", line 688, in __init__ self._setup(self._connection_class(host, port)) File "C:\Python22\lib\httplib.py", line 343, in __init__ self._set_hostport(host, port) File "C:\Python22\lib\httplib.py", line 349, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): I managed to track the problem down to the function open_http() in urllib.py. The value of the 'host' variable contained the string 'http:' rather than 'www.python.org', when a call is made as follows: httplib.HTTP(host) Line 272 of urllib.py should be setting the variable 'host' to the value of 'realhost' but the statement is never executed. The function 'proxy_bypas ()' doesn't appear to do anything but return 0. I fixed it for my own purposes by adding a statement: host = realhost ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-16 09:31 Message: Logged In: YES user_id=11105 The (my) conclusion of all this is: # Per-protocol settings for p in proxyServer.split(';'): protocol, address = p.split('=', 1) proxies[protocol] = '%s://%s' % (protocol, address) It should add a "http://" prefix if one isn't already there. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-16 07:37 Message: Logged In: YES user_id=426262 I have found the document that theller referred to online, the URL is: http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk /Ch13_d.htm or alternatively: http://www.microsoft.com/windows2000/techinfo/reskit/en- us/default.asp?url=/WINDOWS2000/techinfo/reskit/en- us/ierk/Ch13_d.asp The actual registry entries that I posted earlier appear to be set by Windows2000/IE6. If you make the following series of clicks from IE: Tools | Internet Options | Connections Then in the section: Dial-up and Virtual Private Network settings click the Settings... button, then the Advanced... button under Proxy server, you will see a list of proxy servers for different protocols. If I add a fake proxy server for Gopher, such as: http://www-cache.sachmoz.com with port 8080, the registry key data is altered to: ftp=http://www-cache.freeserve.com:8080;gopher=http://www- cache.sachmoz.com:8080;http=http://www- cache.freeserve.com:8080 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=11105 Here's a quote from Microsoft docs (Windows 2000 Server Resource Kit). I have not found it online, but it's in my local MSDN library April 2001: MSDNLibrary -> Resource Kits -> Windows 2000 Server Resource Kit -> Internet Explorer 5 Resource Kit -> Part 3: Customizing -> Chapter 13: Setting up Servers -> Working with Proxy Servers Proxy locations that do not begin with a protocol (such as http:// or ftp://) are assumed to be a CERN-type HTTP proxy. For example, when the user types proxy, it's treated the same as if the user typed http://proxy. For FTP gateways, such as the TIS FTP gateway, the proxy should be listed with the ftp:// in front of the proxy name. For example, an FTP gateway for an FTP proxy would have this format: ftp://ftpproxy When you enter proxy settings, use the following syntax, where
is the Web address of the proxy server and is the port number assigned to the proxy server: http://
: For example, if the address of the proxy server is proxy.example.microsoft.com and the port number is 80, the setting in the Proxy Server box for LAN settings in the Proxy Settings dialog box or the Proxy Settings screen of the Customization wizard should read as follows: http://proxy.example.microsoft.com:80 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:58 Message: Logged In: YES user_id=11105 Isn't the correct setting for an ftp proxy "http://192.168.0.15:3128" instead of "ftp://192.168.0.15:3128". At least, in Python 2.1, only the former works for me. In Python 2.2 neither does, but maybe that's a different issue. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 12:18 Message: Logged In: YES user_id=6380 Looks like this code block in getproxies_registry() is broken then: # Per-protocol settings for p in proxyServer.split(';'): protocol, address = p.split('=', 1) proxies[protocol] = '%s://%s' % (protocol, address) It should only add the :// prefix if one isn't already there. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-15 12:07 Message: Logged In: YES user_id=11105 It seems sachmoz registry settings are valid for IE, I checked this by changing my own settings from ftp=192.168.0.15:3128;http=192.168.0.13:3128 to ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128 IE works either before or after this change. Here's the only article I found on MSDN showing an example: http://support.microsoft.com/default.aspx?scid=kb;EN- US;q164035 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 11:24 Message: Logged In: YES user_id=6380 I'm assigning this to Mark Hammond, who knows more about the Windows registry. Could there be a bug in the function getproxies_registry()? See the last two posts from sachmoz; ignore the original problem description. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-15 10:17 Message: Logged In: YES user_id=426262 The actual settings in the registry look slightly different: http=http://www-cache.freeserve.com:8080;ftp=http://www- cache.freeserve.com:8080 Notice the '=' signs. These settings have been set automatically by Freeserve, and so there are perhaps millions of people in the UK with the same registry settings (and therefore the same problem). I have mailed Freeserve to ask them to confirm if the settings are correct. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 09:46 Message: Logged In: YES user_id=6380 If that's really what getproxies_registry() prints, then look again at the URL in the dict for key 'http'. It says 'http://http://www-cache.freeserve.com:8080' In other words a double http:// prefix!!! If you fix the registry the problem will go away. I don't think this is a problem with urllib.py. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-14 05:04 Message: Logged In: YES user_id=426262 I hope this is what you need: >>> print getproxies_environment() {} >>> print getproxies_registry() {'ftp': 'ftp://http://www- cache.freeserve.com:8080', 'http': 'http://http://www- cache.freeserve.com:8080'} >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 20:46 Message: Logged In: YES user_id=6380 Hm, you can only ever end up in that code block if you have some kind of proxy settings active. On Windows, those are in the registry, even if you think they are not. Your fix is clearly not right -- but in order to find out what is right, I need your proxy settings. ---------------------------------------------------------------------- Comment By: Jason Cowley (sachmoz) Date: 2002-01-13 14:35 Message: Logged In: YES user_id=426262 I am not using a proxy, but I have a dial-up connection to an ISP and I am using Windows 2000. The Python version info is: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Here is the modification I made to urllib.py: 272: if proxy_bypass(realhost): 273: host = realhost # this line was not being executed 274: host = realhost # I added this to fix urlopen() Without this line I added, the following statement was being executed 9-10 lines below, with 'http:' as the value of host: h = httplib.HTTP(host) Which later caused the problem when _set_hostport in httplib.py tries to convert an empty string to an int on line 349: port = int(host[i+1:]) I have attached my copy of "urllib.py". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-13 13:33 Message: Logged In: YES user_id=6380 I cannot reproduce this. What are your proxy settings? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470 From noreply@sourceforge.net Wed Jan 16 18:02:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 10:02:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8 Message-ID: Bugs item #448351, was opened at 2001-08-06 01:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry Warsaw (bwarsaw) Summary: coredump in selectmodule.c on Solaris 8 Initial Comment: I get coredump if I run a small script with Python 2.0 on Solaris 8, compiled with Sun CC Forte 6.1 compiler (64 bits). I suggest to run it more than once to produce the error. Purify showed me that there are reading and writings outside the stack boundary. The interesting part of the source: Modules/selectmodule.c . . static PyObject * select_select(PyObject *self, PyObject *args) { #ifdef MS_WINDOWS /* This would be an awful lot of stack space on Windows! */ pylist *rfd2obj, *wfd2obj, *efd2obj; #else pylist rfd2obj[FD_SETSIZE + 3]; pylist wfd2obj[FD_SETSIZE + 3]; pylist efd2obj[FD_SETSIZE + 3]; #endif . . . } In our environment FD_SETSIZE is 65536 as defined in sys/select.h (see below). The allocated stack space in select_select is 3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than 3Mbytes. The difference between the addresses of the same variable in two seperate threads is about 2Mbytes. Lets suppose char *p1 = (char *)rfd2obj in thread N and char *p2 = (char *)rfd2obj in thread N + 1, abs(p1-p2) is about 2MB (dbx showed this). The stack is overwritten between the threads. Is it possible that the stack size is limited to 2 Mbytes per thread? We fixed it as solved on Windows allocating these variables on the heap. Select.h from Solaris 8. /usr/include/sys/select.h: . . #ifndef FD_SETSIZE #ifdef _LP64 #define FD_SETSIZE 65536 #else #define FD_SETSIZE 1024 #endif /* _LP64 */ . . ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2002-01-16 10:02 Message: Logged In: YES user_id=32863 Unfortunately 1024 is too much as well. I just finished a long session with Purify on Solaris (with FD_SETSIZE==1024), and stack corruption occurs unless I change the test to "#if FD_SETSIZE > 1023" Maybe the limit should be lowered to 511 so Windows users will get same behaviour as the old code? I have been testing Python 2.2, browsing CVS tells me the code is the same at this point in time. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-10-18 12:48 Message: Logged In: YES user_id=12800 Ah I forgot to close this bug report. This code's been in the source long enough to have uncovered problems if there were any. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-16 14:58 Message: Logged In: YES user_id=31435 Back to Barry for re-testing on Linux: I checked in another version that refuses to add 3 to FD_SETSIZE anymore. Fortune favors the bold. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-08-16 09:53 Message: Logged In: YES user_id=12800 I've just checked in a minimal patch, taking the easy way out (i.e. testing for FD_SETSIZE > 1024). This subtly changes the behavior on Windows (where Tim says the value is now 512) since Windows won't normally take the allocate-on-heap path now. selectmodule.c 2.54 has the change. The changes pass on Linux both for normal, small FD_SETSIZEs and for artificially cranked FD_SETSIZEs. Assigning back to Tim for verification on Windows. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-08-06 13:52 Message: Logged In: YES user_id=31435 Reassigned to Barry. I may a good choice to write the code, but not to test it (I know zilch about sockets, and can't provoke the problem on Windows anyway). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-06 05:36 Message: Logged In: YES user_id=6380 Dear Anonymous, a quick workaround is to change the three #ifdef MS_WINDOWS in selectmodule.c into #if FD_SETSIZE > 1024. A better idea is currently being discussed on python-dev. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-06 01:31 Message: Logged In: NO The attachment missed, this is the mentioned script: import threading import telnetlib def telnetToHost(): hostname = "my_hostname" username = "user_name" password = "password" tn = telnetlib.Telnet(hostname) tn.read_until("login: ") tn.write(username + '\n') tn.read_until("Password: ") tn.write(password + '\n') class MyThread(threading.Thread): def run(self): print "ThreadID", self.cnt, "started" telnetToHost() print "ThreadID", self.cnt, "finished" for i in range(0,4): m = MyThread() m.cnt = i m.start() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470 From noreply@sourceforge.net Wed Jan 16 21:20:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 13:20:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-504611 ] smtplib - multiple addresses bug Message-ID: Bugs item #504611, was opened at 2002-01-16 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504611&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Sergiusz Pawlowicz (serek) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib - multiple addresses bug Initial Comment: Example of code: import smtplib server = "localhost" sendit = smtplib.SMTP(server) sendit.set_debuglevel(1) sendit.sendmail("ser", "ser, ser, ser, ser", "dupa") sendit.quit() Execution: send: 'ehlo XXX.pl\r\n' reply: '250-XXX.pl\r\n' reply: '250-PIPELINING\r\n' reply: '250-STARTTLS\r\n' reply: '250 8BITMIME\r\n' reply: retcode (250); Msg: XXX.pl PIPELINING STARTTLS 8BITMIME send: 'mail FROM:\r\n' reply: '250 ok\r\n' reply: retcode (250); Msg: ok send: 'rcpt TO:\r\n' reply: '250 ok\r\n' reply: retcode (250); Msg: ok send: 'data\r\n' reply: '354 go ahead\r\n' reply: retcode (354); Msg: go ahead data: (354, 'go ahead') send: 'dupa\r\n.\r\n' reply: '250 ok 1011215867 qp 29541\r\n' reply: retcode (250); Msg: ok 1011215867 qp 29541 data: (250, 'ok 1011215867 qp 29541') send: 'quit\r\n' reply: '221 XXX.pl\r\n' reply: retcode (221); Msg: XXX.pl It sends the letter only to first 'ser' address! :-( [and omit next three]. Of course the same situation is when I specify full addresses, eg. ser@XXX.pl ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504611&group_id=5470 From noreply@sourceforge.net Wed Jan 16 21:40:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 13:40:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-504611 ] smtplib - multiple addresses bug Message-ID: Bugs item #504611, was opened at 2002-01-16 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504611&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Sergiusz Pawlowicz (serek) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib - multiple addresses bug Initial Comment: Example of code: import smtplib server = "localhost" sendit = smtplib.SMTP(server) sendit.set_debuglevel(1) sendit.sendmail("ser", "ser, ser, ser, ser", "dupa") sendit.quit() Execution: send: 'ehlo XXX.pl\r\n' reply: '250-XXX.pl\r\n' reply: '250-PIPELINING\r\n' reply: '250-STARTTLS\r\n' reply: '250 8BITMIME\r\n' reply: retcode (250); Msg: XXX.pl PIPELINING STARTTLS 8BITMIME send: 'mail FROM:\r\n' reply: '250 ok\r\n' reply: retcode (250); Msg: ok send: 'rcpt TO:\r\n' reply: '250 ok\r\n' reply: retcode (250); Msg: ok send: 'data\r\n' reply: '354 go ahead\r\n' reply: retcode (354); Msg: go ahead data: (354, 'go ahead') send: 'dupa\r\n.\r\n' reply: '250 ok 1011215867 qp 29541\r\n' reply: retcode (250); Msg: ok 1011215867 qp 29541 data: (250, 'ok 1011215867 qp 29541') send: 'quit\r\n' reply: '221 XXX.pl\r\n' reply: retcode (221); Msg: XXX.pl It sends the letter only to first 'ser' address! :-( [and omit next three]. Of course the same situation is when I specify full addresses, eg. ser@XXX.pl ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-16 13:40 Message: Logged In: NO Shouldn't you be using ["ser", "ser", "ser", "ser"] as the destination instead of "ser, ser, ser, ser"? --Guido (not logged in) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504611&group_id=5470 From noreply@sourceforge.net Thu Jan 17 03:55:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 19:55:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-504723 ] Bad exceptions from pickle Message-ID: Bugs item #504723, was opened at 2002-01-16 19:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504723&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Alexander (bobalex) Assigned to: Nobody/Anonymous (nobody) Summary: Bad exceptions from pickle Initial Comment: Here is an annotated session that shows some incorrect exceptions raised with bad input. I'm assuming that it is intended that when attempting to load a pickle file, we should only have to check for UnpicklingError, not for several other possible exceptions. >>> import sys >>> sys.version '2.2 (#1, Dec 26 2001, 16:14:13) \n[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)]' Problem 1: Attempting to load an empty file produces an EOFError exception, but should probably produce an UnpicklingError exception. This happens with both pickle and cPickle. >>> import cPickle as pickle >>> import pickle as pk >>> f=open("/dev/null") # Empty file >>> ff=StringIO("asdfasdfasdfasdfasdfasdf") # Garbage file >>> pickle.load(f) Traceback (most recent call last): File "", line 1, in ? EOFError >>> pk.load(f) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 977, in load return Unpickler(file).load() File "/usr/lib/python2.2/pickle.py", line 592, in load dispatch[key](self) File "/usr/lib/python2.2/pickle.py", line 606, in load_eof raise EOFError EOFError Problem 2: With cPickle, loading a garbage file produced and IndexError, not an Unpickling error. >>> pk.load(ff) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 977, in load return Unpickler(file).load() File "/usr/lib/python2.2/pickle.py", line 592, in load dispatch[key](self) File "/usr/lib/python2.2/pickle.py", line 746, in load_dict k = self.marker() File "/usr/lib/python2.2/pickle.py", line 600, in marker while stack[k] is not mark: k = k-1 IndexError: list index out of range ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504723&group_id=5470 From noreply@sourceforge.net Thu Jan 17 07:41:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Jan 2002 23:41:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-504723 ] Bad exceptions from pickle Message-ID: Bugs item #504723, was opened at 2002-01-16 19:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504723&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Alexander (bobalex) Assigned to: Nobody/Anonymous (nobody) Summary: Bad exceptions from pickle Initial Comment: Here is an annotated session that shows some incorrect exceptions raised with bad input. I'm assuming that it is intended that when attempting to load a pickle file, we should only have to check for UnpicklingError, not for several other possible exceptions. >>> import sys >>> sys.version '2.2 (#1, Dec 26 2001, 16:14:13) \n[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)]' Problem 1: Attempting to load an empty file produces an EOFError exception, but should probably produce an UnpicklingError exception. This happens with both pickle and cPickle. >>> import cPickle as pickle >>> import pickle as pk >>> f=open("/dev/null") # Empty file >>> ff=StringIO("asdfasdfasdfasdfasdfasdf") # Garbage file >>> pickle.load(f) Traceback (most recent call last): File "", line 1, in ? EOFError >>> pk.load(f) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 977, in load return Unpickler(file).load() File "/usr/lib/python2.2/pickle.py", line 592, in load dispatch[key](self) File "/usr/lib/python2.2/pickle.py", line 606, in load_eof raise EOFError EOFError Problem 2: With cPickle, loading a garbage file produced and IndexError, not an Unpickling error. >>> pk.load(ff) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 977, in load return Unpickler(file).load() File "/usr/lib/python2.2/pickle.py", line 592, in load dispatch[key](self) File "/usr/lib/python2.2/pickle.py", line 746, in load_dict k = self.marker() File "/usr/lib/python2.2/pickle.py", line 600, in marker while stack[k] is not mark: k = k-1 IndexError: list index out of range ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 23:41 Message: Logged In: YES user_id=21627 The documentation of UnpicklingError says Note that other exceptions may also be raised during unpickling, including (but not necessarily limited to) \exception{AttributeError} and \exception{ImportError}. So I'm not so sure that there is a bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504723&group_id=5470 From noreply@sourceforge.net Thu Jan 17 12:30:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 04:30:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-504252 ] More build problems on AIX 4.3 Message-ID: Bugs item #504252, was opened at 2002-01-16 00:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sven Rubben (srubben) Assigned to: Nobody/Anonymous (nobody) Summary: More build problems on AIX 4.3 Initial Comment: When Python-2.2 is configured on AIX, and the build is running (when bug #477487 is solved) , it will produce a lot of errors but they all look the same: unable to execute /usr/local/lib/python2.2/config/ld_so_aix: No such file or directory Reason: In the configure script, the location of the special link script used in the compilation (ld_so_aix) is set to $BINLIBDEST, but it is not there yet. Solution: Change the location of ld_so_aix to the correct dir in the source tree. So change LDSHARED from pointing to $BINLIBDEST/config to $srcdir/Modules and do the same for python.exp. The following patch does the trick: --- configure Wed Jan 16 08:42:56 2002 +++ configure.new Wed Jan 16 08:33:27 2002 @@ -3147,7 +3147,7 @@ case $ac_sys_system/$ac_sys_release in AIX*) BLDSHARED="\/Modules/ld_so_aix \ -bI:Modules/python.exp" - LDSHARED="\/config/ld_so_aix \ -bI:\/config/python.exp" + LDSHARED="\/Modules/ld_so_aix \ -bI:\/Modules/python.exp" ;; BeOS*) BLDSHARED="\/Modules/ld_so_beos $LDLIBRARY" ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 04:30 Message: Logged In: YES user_id=21627 Thanks, committed as Makefile.pre.in 1.74. ---------------------------------------------------------------------- Comment By: Sven Rubben (srubben) Date: 2002-01-16 07:43 Message: Logged In: YES user_id=418821 Ok, I think I understand now. I should read the scripts more carefully before submitting such a comment. Does the attached diff solve it in the correct way? It builds cleanly now with this one. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:02 Message: Logged In: YES user_id=21627 I think the problem is somewhere else: When building Python itself, BLDSHARED should be used. LDSHARED will be appropriate when building extension modules with distutils, so it must point to the installed ld_so_aix, not the one in the source distribution. So in essence, you will need to replace LDSHARED with BLDSHARED in the appropriate places of Makefile.in. Can you place try to come up with a patch that does so, and attach it to this report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504252&group_id=5470 From noreply@sourceforge.net Thu Jan 17 13:45:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 05:45:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 05:45 Message: Logged In: YES user_id=21627 Adding tp_docobject would work, although it may be somewhat hackish (why should we have this kind of redundancy). I'm not sure how you will convert that to the 8bit version, though: what encoding? If you use the default encoding, tp_doc will be sometimes set, sometimes it won't. In any case, I'd encourage you to produce a patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Thu Jan 17 14:19:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 06:19:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 06:19 Message: Logged In: YES user_id=89016 OK, I've attached the patch. Note that I had to change the return value of PyStructSequence_InitType from void to int. Introducing tp_docobject should provide backwards compatibility for C extensions that still want to use tp_doc as char *. If this is not relevant then we could switch to PyObject *tp_doc immediately, but this complicates initializing a static type structure. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 05:45 Message: Logged In: YES user_id=21627 Adding tp_docobject would work, although it may be somewhat hackish (why should we have this kind of redundancy). I'm not sure how you will convert that to the 8bit version, though: what encoding? If you use the default encoding, tp_doc will be sometimes set, sometimes it won't. In any case, I'd encourage you to produce a patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Thu Jan 17 14:25:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 06:25:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-17 06:25 Message: Logged In: YES user_id=6380 Wouldn't it be easier to set the __doc__ attribute in tp_dict and be done with it? That's what classic classes do. The accessor should still be a bit special: it should be implemented as a property (in tp_getsets), and first look for __doc__ in tp_dict and fall back to tp_doc. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 06:19 Message: Logged In: YES user_id=89016 OK, I've attached the patch. Note that I had to change the return value of PyStructSequence_InitType from void to int. Introducing tp_docobject should provide backwards compatibility for C extensions that still want to use tp_doc as char *. If this is not relevant then we could switch to PyObject *tp_doc immediately, but this complicates initializing a static type structure. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 05:45 Message: Logged In: YES user_id=21627 Adding tp_docobject would work, although it may be somewhat hackish (why should we have this kind of redundancy). I'm not sure how you will convert that to the 8bit version, though: what encoding? If you use the default encoding, tp_doc will be sometimes set, sometimes it won't. In any case, I'd encourage you to produce a patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Thu Jan 17 14:48:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 06:48:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-504880 ] Optional argument for dict.popitem() Message-ID: Bugs item #504880, was opened at 2002-01-17 06:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504880&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Optional argument for dict.popitem() Initial Comment: Have dict.popitem() allow an optional argument which specifies a particular rather than arbitrary key to be popped. It should behave like this: class mydict(dict): def popitem( self, key=None ): if key is None: return dict.popitem(self) value = self[key] del self[key] return (key, value) >>> d = {'spam':2, 'eggs':3} >>> print d.popitem('spam') ('spam', 2) >>> print d {'eggs': 3} The motivation is similar to the rationale for .setdefault() in making a simple, fast built-in replacement for a commonly used sequence of dictionary operations ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504880&group_id=5470 From noreply@sourceforge.net Thu Jan 17 16:14:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 08:14:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 08:14 Message: Logged In: YES user_id=89016 This sound much better. With my current patch all the docstrings for the builltin types are gone, because int etc. never goes through typeobject.c/type_new(). I updated the patch to use Guido's method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-17 06:25 Message: Logged In: YES user_id=6380 Wouldn't it be easier to set the __doc__ attribute in tp_dict and be done with it? That's what classic classes do. The accessor should still be a bit special: it should be implemented as a property (in tp_getsets), and first look for __doc__ in tp_dict and fall back to tp_doc. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 06:19 Message: Logged In: YES user_id=89016 OK, I've attached the patch. Note that I had to change the return value of PyStructSequence_InitType from void to int. Introducing tp_docobject should provide backwards compatibility for C extensions that still want to use tp_doc as char *. If this is not relevant then we could switch to PyObject *tp_doc immediately, but this complicates initializing a static type structure. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 05:45 Message: Logged In: YES user_id=21627 Adding tp_docobject would work, although it may be somewhat hackish (why should we have this kind of redundancy). I'm not sure how you will convert that to the 8bit version, though: what encoding? If you use the default encoding, tp_doc will be sometimes set, sometimes it won't. In any case, I'd encourage you to produce a patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Thu Jan 17 19:14:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 11:14:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-505028 ] Super method search quirk Message-ID: Bugs item #505028, was opened at 2002-01-17 11:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Super method search quirk Initial Comment: I think the following qualifies as a bug; I think the call to super(C, self).m() should cause an exception (the super_getattro search should not find the m in A if an m is defined in B): >>> class A(object): ... def m(self): ... print 'A' ... >>> class B(A): ... m = property(lambda self: 'B') ... >>> class C(B): ... def m(self): ... super(C, self).m() ... print 'C' ... >>> c = C() >>> c.meth() A C ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470 From noreply@sourceforge.net Thu Jan 17 23:10:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 15:10:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-505150 ] mac module documentation inaccuracy. Message-ID: Bugs item #505150, was opened at 2002-01-17 15:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505150&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Jack Jansen (jackjansen) Summary: mac module documentation inaccuracy. Initial Comment: The documentation at for the MacPython 2.2 mac module says, in part: > ==snip== >> One additional function is available: >> >> xstat(path) >> This function returns the same information as stat(), >> but with three additional values appended: the size of the >> resource fork of the file and its >> 4-character creator and type. > ==snip== The xstat() function is available only under PPC MacPython but not under Carbon MacPython. The documentation should be updated, assuming the ommision was intentional. Ideally, it would suggest alternatives for the Carbon version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505150&group_id=5470 From noreply@sourceforge.net Thu Jan 17 23:16:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 15:16:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-505152 ] pprint should (optionally) use str Message-ID: Bugs item #505152, was opened at 2002-01-17 15:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505152&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pprint should (optionally) use str Initial Comment: pprint.pprint() uses repr to display an object. However I think it's at least as likely that pretty printing would be used as a human debugging tool rather than for generating a string "which can be used as input to the interpreter". pprint.pprint() -- and PrettyPrinter.pprint() should optionally use str() to print a human readable representation of the object. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505152&group_id=5470 From noreply@sourceforge.net Thu Jan 17 23:23:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Jan 2002 15:23:25 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-504880 ] Optional argument for dict.popitem() Message-ID: Feature Requests item #504880, was opened at 2002-01-17 06:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=504880&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Optional argument for dict.popitem() Initial Comment: Have dict.popitem() allow an optional argument which specifies a particular rather than arbitrary key to be popped. It should behave like this: class mydict(dict): def popitem( self, key=None ): if key is None: return dict.popitem(self) value = self[key] del self[key] return (key, value) >>> d = {'spam':2, 'eggs':3} >>> print d.popitem('spam') ('spam', 2) >>> print d {'eggs': 3} The motivation is similar to the rationale for .setdefault() in making a simple, fast built-in replacement for a commonly used sequence of dictionary operations ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 15:23 Message: Logged In: YES user_id=21627 Moved into feature requests tracker. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=504880&group_id=5470 From noreply@sourceforge.net Fri Jan 18 10:14:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 02:14:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-505315 ] free vars sometimes show up in locals() Message-ID: Bugs item #505315, was opened at 2002-01-18 02:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Cesar Douady (douady) Assigned to: Nobody/Anonymous (nobody) Summary: free vars sometimes show up in locals() Initial Comment: Python 2.2 under Linux. Whether free variables are part of the local dictionary or not is unclear from the doc, but certainly the following description is buggy: > in : > > def foo(): > x=1 > def bar(): > x > print locals() > bar() > foo() > > the result is "{}", indicating that x is not in locals(). But in : > > def foo(): > x=1 > def bar(): > x > y=1 > print locals() > bar() > foo() > > the result is "{'y':1, 'x':1}", indicating that the presence of y has > made x part of locals(). The above is supported by Michael Hudson and he suggested to assign this bug report to Jeremy. Also in : def foo(): x=1 class bar: x y=1 print dir(bar) foo() the result is "['__doc__', '__module__', 'y']", showing that x was not included. This means that the local dictionary for a class (which is supposed to make up the class dictionary) and for a function is not the same if free variables are ever to be considered as part of the local dictionary. Looking at the interpreter code, the problem lies in PyFrame_FastToLocals() (Objects/frameobject.c:406) where there is a test for (f->f_nlocals == NULL) which prevents free and cell variables from being transfered. It is unclear whether this is an optimization fossile from before nested scopes or whether this is done on purpose to differenciate the behavior between functions (which almost always have locals) and classes (for which nlocals is 0 when PyFrame_FastToLocals is called). In my opinion, the test should be suppressed and cell variables should not be transfered to the local dict, but this breaks the current test suite (in particular test_scope). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470 From noreply@sourceforge.net Fri Jan 18 13:48:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 05:48:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-505315 ] free vars sometimes show up in locals() Message-ID: Bugs item #505315, was opened at 2002-01-18 02:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Cesar Douady (douady) >Assigned to: Jeremy Hylton (jhylton) Summary: free vars sometimes show up in locals() Initial Comment: Python 2.2 under Linux. Whether free variables are part of the local dictionary or not is unclear from the doc, but certainly the following description is buggy: > in : > > def foo(): > x=1 > def bar(): > x > print locals() > bar() > foo() > > the result is "{}", indicating that x is not in locals(). But in : > > def foo(): > x=1 > def bar(): > x > y=1 > print locals() > bar() > foo() > > the result is "{'y':1, 'x':1}", indicating that the presence of y has > made x part of locals(). The above is supported by Michael Hudson and he suggested to assign this bug report to Jeremy. Also in : def foo(): x=1 class bar: x y=1 print dir(bar) foo() the result is "['__doc__', '__module__', 'y']", showing that x was not included. This means that the local dictionary for a class (which is supposed to make up the class dictionary) and for a function is not the same if free variables are ever to be considered as part of the local dictionary. Looking at the interpreter code, the problem lies in PyFrame_FastToLocals() (Objects/frameobject.c:406) where there is a test for (f->f_nlocals == NULL) which prevents free and cell variables from being transfered. It is unclear whether this is an optimization fossile from before nested scopes or whether this is done on purpose to differenciate the behavior between functions (which almost always have locals) and classes (for which nlocals is 0 when PyFrame_FastToLocals is called). In my opinion, the test should be suppressed and cell variables should not be transfered to the local dict, but this breaks the current test suite (in particular test_scope). ---------------------------------------------------------------------- >Comment By: Cesar Douady (douady) Date: 2002-01-18 05:48 Message: Logged In: YES user_id=428521 I made a typo in the last paragraph. I actually meant cell variables should always be transfered to the local dict while free variables should not. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470 From noreply@sourceforge.net Fri Jan 18 15:49:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 07:49:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-505417 ] Dynamic loading bug on HPUX Message-ID: Bugs item #505417, was opened at 2002-01-18 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic loading bug on HPUX Initial Comment: When a shared library is found on HPUX, but the requested symbol cannot be found, the dynamic loading function returns a random pointer, causing a crash soon afterwards. Python/dynload_hpux.c, line 50: shl_findsym(&lib, funcname, TYPE_UNDEFINED, (void *) &p); I suggest initializing p to NULL explicitly or checking the return value of shl_findsym(): -1 is returned on error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 From noreply@sourceforge.net Fri Jan 18 16:01:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 08:01:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-505423 ] Get rid of make frameworkinstall Message-ID: Bugs item #505423, was opened at 2002-01-18 08:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505423&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Get rid of make frameworkinstall Initial Comment: We should get rid of "make frameworkinstall" if you build a framework Python, and in stead have installing the framework be handled with a normal "make install". Various people have been confused by this. Including me. More than once. :-) "make install" for a framework build should also install a symlink in the normal (/usr/local) location, but this may be a bit difficult as the PREFIX variable (and it's dependents such as BINDIR) are forced to point into the framework when we're doing a framework build. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505423&group_id=5470 From noreply@sourceforge.net Fri Jan 18 16:13:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 08:13:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Fri Jan 18 17:32:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 09:32:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Fri Jan 18 17:45:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 09:45:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Fri Jan 18 17:50:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 09:50:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:50 Message: Logged In: YES user_id=52562 I submitted a patch: "[ #505464 ] fix (??) bug in `gc.get_referrers()'" which eliminates the symptoms. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Fri Jan 18 18:57:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 10:57:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-505488 ] python-mode.el sets TMPDIR to /usr/tmp Message-ID: Bugs item #505488, was opened at 2002-01-18 10:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505488&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el sets TMPDIR to /usr/tmp Initial Comment: all python versions. Not sure why, but on most systems this directory does not exist. Probably should be /var/tmp ...(variable py-temp-directory). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505488&group_id=5470 From noreply@sourceforge.net Fri Jan 18 19:00:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 11:00:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-505490 ] Improve I/O redirection to embedding app Message-ID: Bugs item #505490, was opened at 2002-01-18 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Stefan Franke (sfranke) Assigned to: Nobody/Anonymous (nobody) Summary: Improve I/O redirection to embedding app Initial Comment: When embedding Python into an existing application, you usually do two things (among others): 1. Make Python use your own memory allocation 2. Redirect its I/O to the embedding app While the former is very easy due to the excellent pymem.h interface, the latter is quite painful, since the interpreter uses stdin/out/err directly. The common workaround I found on c.l.p is providing your own file-like objects in an extension module and assign them to sys.stdout/err within the interpreter. This solution still has its problems (like getting errors while import site.py) I wish Python would encapsulate I/O in a similar way than its malloc interface, and in some way I would expect this from a language which is said to be designed for extending and embedding. Unluckily I'm not able to this myself. I started my first embedding project a few days ago and still miss the big picture about Python's C API. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 From noreply@sourceforge.net Fri Jan 18 20:50:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 12:50:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 12:50 Message: Logged In: YES user_id=52562 Whoops. The unexplained behavior is actually perfectly well explained -- only one of those objects *does* reference a3. I believe that patch "[ #505464 ] fix (??) bug in `gc.get_referrers()'" fixes this bug. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:50 Message: Logged In: YES user_id=52562 I submitted a patch: "[ #505464 ] fix (??) bug in `gc.get_referrers()'" which eliminates the symptoms. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Fri Jan 18 21:06:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 13:06:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-505417 ] Dynamic loading bug on HPUX Message-ID: Bugs item #505417, was opened at 2002-01-18 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic loading bug on HPUX Initial Comment: When a shared library is found on HPUX, but the requested symbol cannot be found, the dynamic loading function returns a random pointer, causing a crash soon afterwards. Python/dynload_hpux.c, line 50: shl_findsym(&lib, funcname, TYPE_UNDEFINED, (void *) &p); I suggest initializing p to NULL explicitly or checking the return value of shl_findsym(): -1 is returned on error. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:06 Message: Logged In: YES user_id=21627 Can you please refer us to online documentation for shl_findsym? Or betterm can you provide a tested patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 From noreply@sourceforge.net Fri Jan 18 21:09:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 13:09:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Fri Jan 18 21:09:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 13:09:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Fri Jan 18 21:18:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 13:18:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:18 Message: Logged In: YES user_id=21627 I fail to see the bug. You may argue that the object is conceptually dead already. However: a) there are different ways to bring it back into life: activating DEBUG_SAVEALL may bring them back to life, or they may have references originating from an object with an __del__, which are put onto gc.garbage always. b) tracing all objects is desirable, since it will help to explain the reference counter, and may help detecting bugs in extension modules. c) always collecting is expensive. d) if the application wants to, it can always initiate a collection itself. e) Initiating a collection may call back into Python code, thus changing many references in unforeseeable ways; this is undesirable if you have managed to bring the interpreter into a state where you want to analyse it, and then the interpreter messes up everything by invoking a collection. Unless you bring forward arguments why your application cannot initiate a collection itself before invoking get_referrers, I'm tempted to close this report. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 12:50 Message: Logged In: YES user_id=52562 Whoops. The unexplained behavior is actually perfectly well explained -- only one of those objects *does* reference a3. I believe that patch "[ #505464 ] fix (??) bug in `gc.get_referrers()'" fixes this bug. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:50 Message: Logged In: YES user_id=52562 I submitted a patch: "[ #505464 ] fix (??) bug in `gc.get_referrers()'" which eliminates the symptoms. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Fri Jan 18 21:26:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 13:26:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-505490 ] Improve I/O redirection to embedding app Message-ID: Bugs item #505490, was opened at 2002-01-18 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Stefan Franke (sfranke) Assigned to: Nobody/Anonymous (nobody) Summary: Improve I/O redirection to embedding app Initial Comment: When embedding Python into an existing application, you usually do two things (among others): 1. Make Python use your own memory allocation 2. Redirect its I/O to the embedding app While the former is very easy due to the excellent pymem.h interface, the latter is quite painful, since the interpreter uses stdin/out/err directly. The common workaround I found on c.l.p is providing your own file-like objects in an extension module and assign them to sys.stdout/err within the interpreter. This solution still has its problems (like getting errors while import site.py) I wish Python would encapsulate I/O in a similar way than its malloc interface, and in some way I would expect this from a language which is said to be designed for extending and embedding. Unluckily I'm not able to this myself. I started my first embedding project a few days ago and still miss the big picture about Python's C API. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:26 Message: Logged In: YES user_id=21627 I don't think that assigning to sys.stdout etc. is a work-around; it is the proper solution. If you worry about site.py, you can set Py_NoSiteFlag (which may be a good idea in an embedded interpreter, anyway); if you then still need site.py, you can import it on your own. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 From noreply@sourceforge.net Fri Jan 18 22:14:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 14:14:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-505562 ] Summary: "BuildApplet can destory the source file on Mac OS X" Message-ID: Bugs item #505562, was opened at 2002-01-18 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505562&group_id=5470 Category: Macintosh Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: Summary: "BuildApplet can destory the source file on Mac OS X" Initial Comment: If the name of the file dropped on BuildApplet is the right length, BuildApplet will work and then will delete the source file!!! For instance dropping a file named "Cvt cmm -> Igor data 2-0 long name.py" onto BuildApple first produces a working droplet with name: "Cvt cmm -> Igor data 2#7F2E4" and then the source file simply vanishes. It's really gone, too (or perhaps moved and renamed) -- a disk search doesn't turn it up anywhere. Making the file name significantly shorter causes everything to work normally. Making the file name significantly longer causes BuildApplet to exit immediately with no error message and nothing done. There seems to be a magic range of file name lengths that cause the source file to softly and silently vanish away. Configuration: - Mac OS X 10.1.2 - MacPython 2.1.1 configured for Carbon - I have only one disk partition, formatted as Mac OS Extended, with tons of free space. Further details available on request, but I hope the problem is easily reproducible. I tried it many times on my Mac and it always did the same thing. I doubt the contents of the source file is relevant, but if it is, I do have a copy (with a shorter name!). -- Russell ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505562&group_id=5470 From noreply@sourceforge.net Fri Jan 18 22:38:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 14:38:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-221791 ] Error for bad \x escape doesn't mention filename Message-ID: Bugs item #221791, was opened at 2000-11-06 08:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221791&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error for bad \x escape doesn't mention filename Initial Comment: Using: GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I get the following 'error' message: from interscript.languages.interscript_languages import add_translation File "interscript/languages/interscript_languages.py", line 2, in ? from interscript.encoding.utf8 import utf8 ValueError: invalid \x escape in known correct code (i.e. it works on Python 1.5.2). I have examined the function 'parsestr' in 'compile.c', and added debugging prints to find out what is going on. The function _correctly_ processes the string 'utf8' (quotes included), and returns, then the error is generated _without_ entering the routine! This almost certainly must be a bug in egcs-2.91.66. The code in 'parsestr' looks correct to me. It is possible the error can be replicated by downloading and running 'interscript' (without any arguments). Interscript is available at http://interscript.sourceforge.net [Reply to skaller@maxtal.com.au, sorry, I couldn't figure out how to 'log on'] ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 14:38 Message: Logged In: YES user_id=21627 A patch is available at https://sourceforge.net/tracker/?func=detail&aid=500002&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-09-05 12:29 Message: Logged In: YES user_id=31435 A kick in the butt won't help. It has a higher effort/payback ratio than anything else on my plate, and so long as that's true it stays at the bottom of my priority list. If someone else wants to tackle it, great. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 11:20 Message: Logged In: YES user_id=6380 This one can use a kick in the butt -- it's still unsolved! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-12-13 08:56 Message: I lost my changes when moving to my new machine. Wasn't happy with them anyway -- changing the exception from ValueError to SyntaxError was purely a hack, to worm its way thru the maze of hacks already there. As long as it's got to be a hack, better a pleasant hack . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-13 08:02 Message: Tim, I remember you were looking into this. Any luck? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-11-13 14:51 Message: Just noting that this is a bit of a mess to repair: no "2nd phase" compile-time errors report file names or line numbers unless they're SyntaxErrors. The bad \x escape here is one path thru that code; bad \x escapes in Unicode strings are another; likewise for OverflowError due to "too large" integer literal. A fix is in progress. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-11-06 09:04 Message: The error message is legitimate: in Python 2.0, \x escapes must have exactly two hex characters following, and he uses \x0\x0 in his __init__.py module, which generates the error message. But his bug report is also legitimate: the ValueError doesn't mention the file where this is occurring! I'm changing the bug subject to reflect this -- it has nothing to do with egcs 2.91.66. I'm randomly assigning this to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221791&group_id=5470 From noreply@sourceforge.net Fri Jan 18 23:48:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 15:48:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-505587 ] Fix hardlink against NavServices Message-ID: Bugs item #505587, was opened at 2002-01-18 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505587&group_id=5470 Category: Macintosh Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Fix hardlink against NavServices Initial Comment: PPC PythonCore 2.2 apparently hardlinks against NavigationServices, which is not part of standard MacOS 8.1. Most people have it, but not all. Reported by Brian Benjamin , who might also be willing to test a 2.2.1 fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505587&group_id=5470 From noreply@sourceforge.net Sat Jan 19 03:12:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 19:12:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-505628 ] Bad instructions in readme file. Message-ID: Bugs item #505628, was opened at 2002-01-18 19:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Bad instructions in readme file. Initial Comment: The directions in the ...\PC\example_nt\readme.txt in the section titled "CREATING A BRAND NEW PROJECT" says: > Select "Win32 Release" in the "Settings for:" dropdown list. Click the > "Link" tab, choose the "Input" Category, and append "python21.lib" to the > list in the "Object/library modules:" box. Which is not true (any more?) because of a #pragma now in the ...\PC\Config.h file. Namely: > #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) > /* So nobody using MSVC needs to specify the .lib in their Makefile any > more (other compilers will still need to do so, but that's taken care > of by the Distutils, so it's not a problem). */ > #ifdef _DEBUG > #pragma comment(lib,"python21_d.lib") > #else > #pragma comment(lib,"python21.lib") > #endif > #endif /* USE_DL_EXPORT */ Personally I don't care for the #pragma technique -- it's too implicit and compiler specific. If nothing else perhaps the paragraphi in the readme file could be replaced with a mention of how the use of the pragma. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 From noreply@sourceforge.net Sat Jan 19 05:33:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Jan 2002 21:33:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-505628 ] Windows: Bad instructions in readme file. Message-ID: Bugs item #505628, was opened at 2002-01-18 19:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 >Category: Demos and Tools >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) >Assigned to: Tim Peters (tim_one) >Summary: Windows: Bad instructions in readme file. Initial Comment: The directions in the ...\PC\example_nt\readme.txt in the section titled "CREATING A BRAND NEW PROJECT" says: > Select "Win32 Release" in the "Settings for:" dropdown list. Click the > "Link" tab, choose the "Input" Category, and append "python21.lib" to the > list in the "Object/library modules:" box. Which is not true (any more?) because of a #pragma now in the ...\PC\Config.h file. Namely: > #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) > /* So nobody using MSVC needs to specify the .lib in their Makefile any > more (other compilers will still need to do so, but that's taken care > of by the Distutils, so it's not a problem). */ > #ifdef _DEBUG > #pragma comment(lib,"python21_d.lib") > #else > #pragma comment(lib,"python21.lib") > #endif > #endif /* USE_DL_EXPORT */ Personally I don't care for the #pragma technique -- it's too implicit and compiler specific. If nothing else perhaps the paragraphi in the readme file could be replaced with a mention of how the use of the pragma. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-18 21:33 Message: Logged In: YES user_id=31435 Sorry, I don't understand your complaint. The instruction appears accurate to me, and should work whether or not the #pragma is there. Besides, it *is* what's done in the example.dsw project, and that project works fine. What exactly is it that you believe is "not true"? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 From noreply@sourceforge.net Sat Jan 19 09:24:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Jan 2002 01:24:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-505628 ] Windows: Bad instructions in readme file. Message-ID: Bugs item #505628, was opened at 2002-01-18 19:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 Category: Demos and Tools Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Tim Peters (tim_one) Summary: Windows: Bad instructions in readme file. Initial Comment: The directions in the ...\PC\example_nt\readme.txt in the section titled "CREATING A BRAND NEW PROJECT" says: > Select "Win32 Release" in the "Settings for:" dropdown list. Click the > "Link" tab, choose the "Input" Category, and append "python21.lib" to the > list in the "Object/library modules:" box. Which is not true (any more?) because of a #pragma now in the ...\PC\Config.h file. Namely: > #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) > /* So nobody using MSVC needs to specify the .lib in their Makefile any > more (other compilers will still need to do so, but that's taken care > of by the Distutils, so it's not a problem). */ > #ifdef _DEBUG > #pragma comment(lib,"python21_d.lib") > #else > #pragma comment(lib,"python21.lib") > #endif > #endif /* USE_DL_EXPORT */ Personally I don't care for the #pragma technique -- it's too implicit and compiler specific. If nothing else perhaps the paragraphi in the readme file could be replaced with a mention of how the use of the pragma. ---------------------------------------------------------------------- >Comment By: Martin Miller (mrmiller) Date: 2002-01-19 01:24 Message: Logged In: YES user_id=257085 It is not true because it is not necessary, due to the use of the pragma. The section in the readme is for "CREATING A BRAND NEW PROJECT", but it is not necessary to do what is specified there to the project settings. Since example.dsw builds, it only means that specifying the library in both places doesn't result in any fatal errors. That means having the #pragma AND specifying the library in the project setting is only redundant, but is apparently non-fatal. (So why have the #pragma?) In my case it was particularly confusing because I was comparing someone else's Mac CodeWarrior (which doesn't support the pragma) project which explicitly specified linking to the library, to a similar one for Windows which used VC++, when I noticed that no Python library was specified in the latter. I wondered why, based on what I had read in the readme file. Eventually I discovered the #pragma in the config.h file almost by sheer luck, however finding it explained how the VC++ project was able to build despite, apparently, not following the directions. To turn things around a little bit, ask yourself why are the instructions there, what is their purpose? Is it keeping things a simple as possible for those starting out to put unneeded steps into the readme? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-18 21:33 Message: Logged In: YES user_id=31435 Sorry, I don't understand your complaint. The instruction appears accurate to me, and should work whether or not the #pragma is there. Besides, it *is* what's done in the example.dsw project, and that project works fine. What exactly is it that you believe is "not true"? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 From noreply@sourceforge.net Sat Jan 19 09:40:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Jan 2002 01:40:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-505628 ] Windows: Bad instructions in readme file. Message-ID: Bugs item #505628, was opened at 2002-01-18 19:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 Category: Demos and Tools >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Tim Peters (tim_one) Summary: Windows: Bad instructions in readme file. Initial Comment: The directions in the ...\PC\example_nt\readme.txt in the section titled "CREATING A BRAND NEW PROJECT" says: > Select "Win32 Release" in the "Settings for:" dropdown list. Click the > "Link" tab, choose the "Input" Category, and append "python21.lib" to the > list in the "Object/library modules:" box. Which is not true (any more?) because of a #pragma now in the ...\PC\Config.h file. Namely: > #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) > /* So nobody using MSVC needs to specify the .lib in their Makefile any > more (other compilers will still need to do so, but that's taken care > of by the Distutils, so it's not a problem). */ > #ifdef _DEBUG > #pragma comment(lib,"python21_d.lib") > #else > #pragma comment(lib,"python21.lib") > #endif > #endif /* USE_DL_EXPORT */ Personally I don't care for the #pragma technique -- it's too implicit and compiler specific. If nothing else perhaps the paragraphi in the readme file could be replaced with a mention of how the use of the pragma. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-19 01:40 Message: Logged In: YES user_id=31435 OK, your objection isn't that the docs are incorrect, but that they ask you to do a step that isn't necessary, *given* the details of how things happen to be implemented today. But they may not be implemented that way tomorrow; indeed, you yourself originally said you don't like the #pragma technique. Follow the instructions as given and you're safe even if we get rid of that; cheat by depending on details of the current implementation, and you deserve whatever you get in the future. That's your choice, but I intend to leave the current instructions alone because changing them would lock us into using the #pragma gimmick (or something equally "implicit and compiler specific") forever. ---------------------------------------------------------------------- Comment By: Martin Miller (mrmiller) Date: 2002-01-19 01:24 Message: Logged In: YES user_id=257085 It is not true because it is not necessary, due to the use of the pragma. The section in the readme is for "CREATING A BRAND NEW PROJECT", but it is not necessary to do what is specified there to the project settings. Since example.dsw builds, it only means that specifying the library in both places doesn't result in any fatal errors. That means having the #pragma AND specifying the library in the project setting is only redundant, but is apparently non-fatal. (So why have the #pragma?) In my case it was particularly confusing because I was comparing someone else's Mac CodeWarrior (which doesn't support the pragma) project which explicitly specified linking to the library, to a similar one for Windows which used VC++, when I noticed that no Python library was specified in the latter. I wondered why, based on what I had read in the readme file. Eventually I discovered the #pragma in the config.h file almost by sheer luck, however finding it explained how the VC++ project was able to build despite, apparently, not following the directions. To turn things around a little bit, ask yourself why are the instructions there, what is their purpose? Is it keeping things a simple as possible for those starting out to put unneeded steps into the readme? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-18 21:33 Message: Logged In: YES user_id=31435 Sorry, I don't understand your complaint. The instruction appears accurate to me, and should work whether or not the #pragma is there. Besides, it *is* what's done in the example.dsw project, and that project works fine. What exactly is it that you believe is "not true"? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505628&group_id=5470 From noreply@sourceforge.net Sat Jan 19 11:07:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Jan 2002 03:07:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- >Comment By: Zooko Ozoko (zooko) Date: 2002-01-19 03:07 Message: Logged In: YES user_id=52562 loewis: Those are good points. Hm. The reason I consider it a bug is that it bit me. I was trying to analyze memory usage in my application, and I got some confusing results, and then finally I recognized one of the objects as a temporary that I had created and destroyed earlier. Of course, if I had thought explicitly about the question of "does `get_referrers()' include dead but not collected cyclical objects?" I would have known the answer correctly, but I didn't think about it and just acted as though things that get de-linked (given that they had no __del__ methods) are effectively gone forever. But you made very good points, so I suggest changing the documentation, something like this: Index: dist/src/Doc/lib/libgc.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libgc.tex,v retrieving revision 1.9 diff -u -d -r1.9 libgc.tex --- dist/src/Doc/lib/libgc.tex 2001/12/14 21:19:08 1.9 +++ dist/src/Doc/lib/libgc.tex 2002/01/19 10:40:31 @@ -83,6 +83,11 @@ function will only locate those containers which support garbage collection; extension types which do refer to other objects but do not support garbage collection will not be found. + +Note that objects which have already been dereferenced, but which +live in cycles and have not yet been collected by the garbage collector +can be listed among the resulting referrers. To get only currently live +objects, call \function{collect()} before calling \function{get_referrers()}. \versionadded{2.2} \end{funcdesc} ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:18 Message: Logged In: YES user_id=21627 I fail to see the bug. You may argue that the object is conceptually dead already. However: a) there are different ways to bring it back into life: activating DEBUG_SAVEALL may bring them back to life, or they may have references originating from an object with an __del__, which are put onto gc.garbage always. b) tracing all objects is desirable, since it will help to explain the reference counter, and may help detecting bugs in extension modules. c) always collecting is expensive. d) if the application wants to, it can always initiate a collection itself. e) Initiating a collection may call back into Python code, thus changing many references in unforeseeable ways; this is undesirable if you have managed to bring the interpreter into a state where you want to analyse it, and then the interpreter messes up everything by invoking a collection. Unless you bring forward arguments why your application cannot initiate a collection itself before invoking get_referrers, I'm tempted to close this report. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 12:50 Message: Logged In: YES user_id=52562 Whoops. The unexplained behavior is actually perfectly well explained -- only one of those objects *does* reference a3. I believe that patch "[ #505464 ] fix (??) bug in `gc.get_referrers()'" fixes this bug. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:50 Message: Logged In: YES user_id=52562 I submitted a patch: "[ #505464 ] fix (??) bug in `gc.get_referrers()'" which eliminates the symptoms. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Sat Jan 19 14:37:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Jan 2002 06:37:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-505747 ] markupbase handling of HTML declarations Message-ID: Bugs item #505747, was opened at 2002-01-19 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: markupbase handling of HTML declarations Initial Comment: Using Python 2.2., I tried to use websucker.py on this page: http://magix.fri.uni-lj.si/orange/start/ This resulted in an exception in ParserBase._scan_name because _declname_match failed. Examining the source for the page above, I see there are several tags that look like: "" where the first character after " Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Nobody/Anonymous (nobody) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Sun Jan 20 15:05:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 07:05:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Nobody/Anonymous (nobody) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Sun Jan 20 18:13:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 10:13:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-506100 ] commands.getstatusoutput(): DOS support Message-ID: Bugs item #506100, was opened at 2002-01-20 10:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Pierre Rouleau (pierre_rouleau) Assigned to: Nobody/Anonymous (nobody) Summary: commands.getstatusoutput(): DOS support Initial Comment: ##commands.getstatusoutput(): Does not support for DOS-type shells # ------------------------------------------------------------- # # Inside commands.py, the getstatusoutput() function is not capable of running a # DOS-type shell command. The current code assumes that the operating system # is running a Unix-type shell. # # The old code is: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text # I propose that we update that code to check the operating system and support # DOS-style shells (for DOS, NT, OS/2) with the following modified code: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os if os.name in ['nt', 'dos', 'os2'] : # use Dos style command shell for NT, DOS and OS/2 pipe = os.popen(cmd + ' 2>&1', 'r') else : # use Unix style for all others pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 From noreply@sourceforge.net Sun Jan 20 18:21:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 10:21:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Zooko Ozoko (zooko) >Assigned to: Martin v. Löwis (loewis) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-19 03:07 Message: Logged In: YES user_id=52562 loewis: Those are good points. Hm. The reason I consider it a bug is that it bit me. I was trying to analyze memory usage in my application, and I got some confusing results, and then finally I recognized one of the objects as a temporary that I had created and destroyed earlier. Of course, if I had thought explicitly about the question of "does `get_referrers()' include dead but not collected cyclical objects?" I would have known the answer correctly, but I didn't think about it and just acted as though things that get de-linked (given that they had no __del__ methods) are effectively gone forever. But you made very good points, so I suggest changing the documentation, something like this: Index: dist/src/Doc/lib/libgc.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libgc.tex,v retrieving revision 1.9 diff -u -d -r1.9 libgc.tex --- dist/src/Doc/lib/libgc.tex 2001/12/14 21:19:08 1.9 +++ dist/src/Doc/lib/libgc.tex 2002/01/19 10:40:31 @@ -83,6 +83,11 @@ function will only locate those containers which support garbage collection; extension types which do refer to other objects but do not support garbage collection will not be found. + +Note that objects which have already been dereferenced, but which +live in cycles and have not yet been collected by the garbage collector +can be listed among the resulting referrers. To get only currently live +objects, call \function{collect()} before calling \function{get_referrers()}. \versionadded{2.2} \end{funcdesc} ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:18 Message: Logged In: YES user_id=21627 I fail to see the bug. You may argue that the object is conceptually dead already. However: a) there are different ways to bring it back into life: activating DEBUG_SAVEALL may bring them back to life, or they may have references originating from an object with an __del__, which are put onto gc.garbage always. b) tracing all objects is desirable, since it will help to explain the reference counter, and may help detecting bugs in extension modules. c) always collecting is expensive. d) if the application wants to, it can always initiate a collection itself. e) Initiating a collection may call back into Python code, thus changing many references in unforeseeable ways; this is undesirable if you have managed to bring the interpreter into a state where you want to analyse it, and then the interpreter messes up everything by invoking a collection. Unless you bring forward arguments why your application cannot initiate a collection itself before invoking get_referrers, I'm tempted to close this report. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 12:50 Message: Logged In: YES user_id=52562 Whoops. The unexplained behavior is actually perfectly well explained -- only one of those objects *does* reference a3. I believe that patch "[ #505464 ] fix (??) bug in `gc.get_referrers()'" fixes this bug. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:50 Message: Logged In: YES user_id=52562 I submitted a patch: "[ #505464 ] fix (??) bug in `gc.get_referrers()'" which eliminates the symptoms. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Mon Jan 21 03:38:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 19:38:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Mon Jan 21 04:20:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 20:20:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- >Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-20 20:20 Message: Logged In: YES user_id=196786 Thanks for responding. The docstring was from Python 2.1.2 (Debian 2.1.2-2): Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) In 2.2, it seems to be corrected: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) The library documentation for 2.2 still says that maxsplit defaults to 0, though apparently it defaults to -1, so that needs to be fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Mon Jan 21 04:30:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 20:30:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 20:30 Message: Logged In: NO Tim was looking at the doc string for the split *method* of string objects, which is correct. But the complaint was about the split *function* in the (no longer needed, but still supported) string *module*, which is indeed wrong -- still in 2.2. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-20 20:20 Message: Logged In: YES user_id=196786 Thanks for responding. The docstring was from Python 2.1.2 (Debian 2.1.2-2): Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) In 2.2, it seems to be corrected: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) The library documentation for 2.2 still says that maxsplit defaults to 0, though apparently it defaults to -1, so that needs to be fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Mon Jan 21 04:45:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Jan 2002 20:45:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-20 20:45 Message: Logged In: YES user_id=31435 Guido's right, I did print "".split.__doc__ without even considering that someone may still be doing the archaic print string.split.__doc__ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 20:30 Message: Logged In: NO Tim was looking at the doc string for the split *method* of string objects, which is correct. But the complaint was about the split *function* in the (no longer needed, but still supported) string *module*, which is indeed wrong -- still in 2.2. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-20 20:20 Message: Logged In: YES user_id=196786 Thanks for responding. The docstring was from Python 2.1.2 (Debian 2.1.2-2): Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) In 2.2, it seems to be corrected: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) The library documentation for 2.2 still says that maxsplit defaults to 0, though apparently it defaults to -1, so that needs to be fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Mon Jan 21 08:38:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 00:38:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- >Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-21 00:38 Message: Logged In: YES user_id=196786 By the way, the reason I ended up looking at the library docs (and docstring) for the string module was that I did a simple text search on index.html from the library reference (I'm new to Python). The first match is UserString, and the second is 4. String Services, under which can be found section 4.1 "string -- Common string operations". "string" is in a monospaced font, and looks as much like a type as a module name, so I assumed that it applied to the built-in string type. I later found the documentation for the string type in section 2.2.6.1 "String Methods". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 20:45 Message: Logged In: YES user_id=31435 Guido's right, I did print "".split.__doc__ without even considering that someone may still be doing the archaic print string.split.__doc__ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 20:30 Message: Logged In: NO Tim was looking at the doc string for the split *method* of string objects, which is correct. But the complaint was about the split *function* in the (no longer needed, but still supported) string *module*, which is indeed wrong -- still in 2.2. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-20 20:20 Message: Logged In: YES user_id=196786 Thanks for responding. The docstring was from Python 2.1.2 (Debian 2.1.2-2): Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) In 2.2, it seems to be corrected: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) The library documentation for 2.2 still says that maxsplit defaults to 0, though apparently it defaults to -1, so that needs to be fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Mon Jan 21 09:00:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 01:00:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11 Message-ID: Bugs item #506349, was opened at 2002-01-21 01:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Harald Koschinski (astir) Assigned to: Nobody/Anonymous (nobody) Summary: Zope crashing with signal 11 Initial Comment: after switching to python 2.1.2 compiled with GC (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) the crashes are back again :-((((((((((((((((((((((( ------------------------------------------------------------------------------------- 2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11 2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11 2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11 2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan 21 09:30:43 2002: Aiieee! 6749 exited with error code: 11 ----------------------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 From noreply@sourceforge.net Mon Jan 21 09:39:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 01:39:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11 Message-ID: Bugs item #506349, was opened at 2002-01-21 01:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Harald Koschinski (astir) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Zope crashing with signal 11 Initial Comment: after switching to python 2.1.2 compiled with GC (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) the crashes are back again :-((((((((((((((((((((((( ------------------------------------------------------------------------------------- 2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11 2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11 2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11 2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan 21 09:30:43 2002: Aiieee! 6749 exited with error code: 11 ----------------------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-21 01:39 Message: Logged In: YES user_id=29957 Which version of Zope are you running? Does it have the RestrictedCompiler fix? As far as I am aware, Zope 2.4 includes it's own version of the Compiler code, and the current release of 2.4 still has the stacksize bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 From noreply@sourceforge.net Mon Jan 21 10:14:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 02:14:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-505490 ] Improve I/O redirection to embedding app Message-ID: Bugs item #505490, was opened at 2002-01-18 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Stefan Franke (sfranke) Assigned to: Nobody/Anonymous (nobody) Summary: Improve I/O redirection to embedding app Initial Comment: When embedding Python into an existing application, you usually do two things (among others): 1. Make Python use your own memory allocation 2. Redirect its I/O to the embedding app While the former is very easy due to the excellent pymem.h interface, the latter is quite painful, since the interpreter uses stdin/out/err directly. The common workaround I found on c.l.p is providing your own file-like objects in an extension module and assign them to sys.stdout/err within the interpreter. This solution still has its problems (like getting errors while import site.py) I wish Python would encapsulate I/O in a similar way than its malloc interface, and in some way I would expect this from a language which is said to be designed for extending and embedding. Unluckily I'm not able to this myself. I started my first embedding project a few days ago and still miss the big picture about Python's C API. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-01-21 02:14 Message: Logged In: YES user_id=45365 Assigning to sys.stdout and friends is only half a solution: you don't get tracebacks and any other output produced by the C code. Unfortunately there is no platform-independent solution without getting rid of stdio completely. Fortunately there are platform-dependent solutions for many platforms. MacPython has a lowlevel hook to do this, for instance. Depending on your stdio implementation you may be able to hook into stdio on a low level. An alternative 90% solution is to do the sys.stdout assignment and add Python code to print your tracebacks and such. An example of such code can be found in Idle (or IDE, or PythonWin, or any other windowing Python IDE). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:26 Message: Logged In: YES user_id=21627 I don't think that assigning to sys.stdout etc. is a work-around; it is the proper solution. If you worry about site.py, you can set Py_NoSiteFlag (which may be a good idea in an embedded interpreter, anyway); if you then still need site.py, you can import it on your own. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 From noreply@sourceforge.net Mon Jan 21 10:23:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 02:23:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11 Message-ID: Bugs item #506349, was opened at 2002-01-21 01:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Harald Koschinski (astir) Assigned to: Anthony Baxter (anthonybaxter) Summary: Zope crashing with signal 11 Initial Comment: after switching to python 2.1.2 compiled with GC (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) the crashes are back again :-((((((((((((((((((((((( ------------------------------------------------------------------------------------- 2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11 2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11 2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11 2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan 21 09:30:43 2002: Aiieee! 6749 exited with error code: 11 ----------------------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-21 02:23 Message: Logged In: YES user_id=29957 Which version of Zope are you running? Does it have the RestrictedCompiler fix? As far as I am aware, Zope 2.4 includes it's own version of the Compiler code, and the current release of 2.4 still has the stacksize bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-21 01:39 Message: Logged In: YES user_id=29957 Which version of Zope are you running? Does it have the RestrictedCompiler fix? As far as I am aware, Zope 2.4 includes it's own version of the Compiler code, and the current release of 2.4 still has the stacksize bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 From noreply@sourceforge.net Mon Jan 21 15:18:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 07:18:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-505417 ] Dynamic loading bug on HPUX Message-ID: Bugs item #505417, was opened at 2002-01-18 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic loading bug on HPUX Initial Comment: When a shared library is found on HPUX, but the requested symbol cannot be found, the dynamic loading function returns a random pointer, causing a crash soon afterwards. Python/dynload_hpux.c, line 50: shl_findsym(&lib, funcname, TYPE_UNDEFINED, (void *) &p); I suggest initializing p to NULL explicitly or checking the return value of shl_findsym(): -1 is returned on error. ---------------------------------------------------------------------- >Comment By: Eddy De Greef (edg) Date: 2002-01-21 07:18 Message: Logged In: YES user_id=73597 The man page says: DIAGNOSTICS If a library cannot be loaded, shl_load() returns NULL and sets errno to indicate the error. All other functions return -1 on error and set errno. If shl_findsym() cannot find the indicated symbol, errno is set to zero. If shl_findsym() finds the indicated symbol but cannot resolve all the symbols it depends on, errno is set to ENOSYM. I've attached a patch (tested on HPUX10 and HPUX11). Apart from checking and returning a NULL pointer, it also unloads the shared library in case the symbol is not found. Without this unloading, the Python build process fails because it tries to remove a text file that is busy (and it's cleaner to unload the library anyhow in case of a failure). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:06 Message: Logged In: YES user_id=21627 Can you please refer us to online documentation for shl_findsym? Or betterm can you provide a tested patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 From noreply@sourceforge.net Mon Jan 21 15:23:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 07:23:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-505417 ] Dynamic loading bug on HPUX Message-ID: Bugs item #505417, was opened at 2002-01-18 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) >Assigned to: Martin v. Löwis (loewis) Summary: Dynamic loading bug on HPUX Initial Comment: When a shared library is found on HPUX, but the requested symbol cannot be found, the dynamic loading function returns a random pointer, causing a crash soon afterwards. Python/dynload_hpux.c, line 50: shl_findsym(&lib, funcname, TYPE_UNDEFINED, (void *) &p); I suggest initializing p to NULL explicitly or checking the return value of shl_findsym(): -1 is returned on error. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-21 07:18 Message: Logged In: YES user_id=73597 The man page says: DIAGNOSTICS If a library cannot be loaded, shl_load() returns NULL and sets errno to indicate the error. All other functions return -1 on error and set errno. If shl_findsym() cannot find the indicated symbol, errno is set to zero. If shl_findsym() finds the indicated symbol but cannot resolve all the symbols it depends on, errno is set to ENOSYM. I've attached a patch (tested on HPUX10 and HPUX11). Apart from checking and returning a NULL pointer, it also unloads the shared library in case the symbol is not found. Without this unloading, the Python build process fails because it tries to remove a text file that is busy (and it's cleaner to unload the library anyhow in case of a failure). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:06 Message: Logged In: YES user_id=21627 Can you please refer us to online documentation for shl_findsym? Or betterm can you provide a tested patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 From noreply@sourceforge.net Mon Jan 21 17:47:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 09:47:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-506545 ] Extending and Embedding Section 3 rework Message-ID: Bugs item #506545, was opened at 2002-01-21 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506545&group_id=5470 Category: Documentation Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Extending and Embedding Section 3 rework Initial Comment: This problem was reported on python-help... Most of what is in Section 3 of the Extending and Embedding manual is outdated. It still gives instructions about building extensions using Modules/Setup and Misc/Makefile.pre.in. This section should probably be reworked to make Distutils more prominent and remove all references to Makefile.pre.in, which isn't even distributed with Python anymore. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506545&group_id=5470 From noreply@sourceforge.net Mon Jan 21 20:17:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 12:17:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile() coredumps Message-ID: Bugs item #506611, was opened at 2002-01-21 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sys.setprofile() coredumps Initial Comment: Verified in current CVS (also on Windows, but doubt the platform matters). It's not the call proper that coredumps, but an eval loop's later attempt to use a resulting NULL pointer. From c.l.py: """ From: rihad Sent: Monday, January 21, 2002 1:19 PM Subject: minor Python bugs Calling sys.setprofile() (with no args) makes the interpreter crash, and calling sys.settrace() with no args succeeds, even though it is documented to take 1 arg (tracefunc). And yes, my version is '2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)]' """ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 From noreply@sourceforge.net Mon Jan 21 21:20:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 13:20:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect? Message-ID: Bugs item #506647, was opened at 2002-01-21 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Maciej Kalisiak (abcdefghijklmno) Assigned to: Nobody/Anonymous (nobody) Summary: random.cunifvariate() incorrect? Initial Comment: random.cunifvariate() currently is defined as: return (mean + arc * (self.random() - 0.5)) % _pi First of all, this returns values in the range [0, pi) due to the modulus, which really makes it a semi-circular distribution, not circular (but I'm not a mathie, so perhaps I'm wrong). I think the normalizing step ("% _pi", or whatever this gets changed to) should probably be mentioned in the documentation for this function; it caught me by surprise, and I expect it will catch some others too. With this defintion, the function returns a random value in the range [mean-arc/2, mean+arc/2). The docs say that arc, like mean, can only be in the range [0,pi]. This would imply that one cannot get values in the other half of the circle, i.e. [pi, 2*pi). Since there doesn't seem to be anything stopping the caller from using an arc in [0,2*pi], perhaps the documentation should be updated? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470 From noreply@sourceforge.net Mon Jan 21 22:36:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 14:36:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-506679 ] Core dump subclassing long Message-ID: Bugs item #506679, was opened at 2002-01-21 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506679&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Socci (nsocci) Assigned to: Nobody/Anonymous (nobody) Summary: Core dump subclassing long Initial Comment: The following code dumps core: class C(long): pass c=C(-1) Note if running interactly the core dump occurs when you quit the interpreter. No problem for positive numbers of if subclassing int or float. Version information: Python 2.2 (#1, Dec 28 2001, 14:02:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506679&group_id=5470 From noreply@sourceforge.net Mon Jan 21 22:39:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 14:39:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile() coredumps Message-ID: Bugs item #506611, was opened at 2002-01-21 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sys.setprofile() coredumps Initial Comment: Verified in current CVS (also on Windows, but doubt the platform matters). It's not the call proper that coredumps, but an eval loop's later attempt to use a resulting NULL pointer. From c.l.py: """ From: rihad Sent: Monday, January 21, 2002 1:19 PM Subject: minor Python bugs Calling sys.setprofile() (with no args) makes the interpreter crash, and calling sys.settrace() with no args succeeds, even though it is documented to take 1 arg (tracefunc). And yes, my version is '2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)]' """ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-21 14:39 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem. The patch includes a test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 From noreply@sourceforge.net Mon Jan 21 22:41:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 14:41:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-506679 ] Core dump subclassing long Message-ID: Bugs item #506679, was opened at 2002-01-21 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506679&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Socci (nsocci) Assigned to: Nobody/Anonymous (nobody) Summary: Core dump subclassing long Initial Comment: The following code dumps core: class C(long): pass c=C(-1) Note if running interactly the core dump occurs when you quit the interpreter. No problem for positive numbers of if subclassing int or float. Version information: Python 2.2 (#1, Dec 28 2001, 14:02:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-21 14:41 Message: Logged In: YES user_id=33168 Here's a stack trace. #0 subtype_dealloc (self=0x818598c) at Objects/typeobject.c:349 #1 0x080c33cc in PyDict_SetItem (op=0x810b8fc, key=0x812a388, value=0x80ddc3c) at Objects/dictobject.c:373 #2 0x080c6189 in _PyModule_Clear (m=0x810b734) at Objects/moduleobject.c:124 #3 0x0808a5d1 in PyImport_Cleanup () at Python/import.c:284 #4 0x08092f1e in Py_Finalize () at Python/pythonrun.c:231 #5 0x080534a6 in Py_Main (argc=1, argv=0xbffff914) at Modules/main.c:376 #6 0x40087507 in __libc_start_main (main=0x8052d70
, argc=1, ubp_av=0xbffff914, init=0x8052194 <_init>, fini=0x80ca4c0 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff90c) at ../sysdeps/generic/libc-start.c:129 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506679&group_id=5470 From noreply@sourceforge.net Mon Jan 21 23:24:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 15:24:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-506679 ] Core dump subclassing long Message-ID: Bugs item #506679, was opened at 2002-01-21 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506679&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Socci (nsocci) >Assigned to: Guido van Rossum (gvanrossum) Summary: Core dump subclassing long Initial Comment: The following code dumps core: class C(long): pass c=C(-1) Note if running interactly the core dump occurs when you quit the interpreter. No problem for positive numbers of if subclassing int or float. Version information: Python 2.2 (#1, Dec 28 2001, 14:02:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-21 15:24 Message: Logged In: YES user_id=6380 Alas, you're right. I suspect a calculation error in the size of the long. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-21 14:41 Message: Logged In: YES user_id=33168 Here's a stack trace. #0 subtype_dealloc (self=0x818598c) at Objects/typeobject.c:349 #1 0x080c33cc in PyDict_SetItem (op=0x810b8fc, key=0x812a388, value=0x80ddc3c) at Objects/dictobject.c:373 #2 0x080c6189 in _PyModule_Clear (m=0x810b734) at Objects/moduleobject.c:124 #3 0x0808a5d1 in PyImport_Cleanup () at Python/import.c:284 #4 0x08092f1e in Py_Finalize () at Python/pythonrun.c:231 #5 0x080534a6 in Py_Main (argc=1, argv=0xbffff914) at Modules/main.c:376 #6 0x40087507 in __libc_start_main (main=0x8052d70
, argc=1, ubp_av=0xbffff914, init=0x8052194 <_init>, fini=0x80ca4c0 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff90c) at ../sysdeps/generic/libc-start.c:129 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506679&group_id=5470 From noreply@sourceforge.net Tue Jan 22 01:53:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Jan 2002 17:53:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-506741 ] ugly floats using str() on tuples,lists Message-ID: Bugs item #506741, was opened at 2002-01-21 17:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506741&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Tim Wegener (twegener) Assigned to: Nobody/Anonymous (nobody) Summary: ugly floats using str() on tuples,lists Initial Comment: Python version 2.1.1 Using str() to make floats look pretty works for str(some_float_variable), but for str(tuple_of_floats) the output floats are still ugly. In Python 2.1.1: >>> a=1.9 >>> a 1.8999999999999999 >>> str(a) '1.9' >>> (a,a) (1.8999999999999999, 1.8999999999999999) >>> str((a,a)) '(1.8999999999999999, 1.8999999999999999)' >>> [a,a] [1.8999999999999999, 1.8999999999999999] >>> str([a,a]) '[1.8999999999999999, 1.8999999999999999]' >>> In Python 1.5.2 >>> a=1.9 >>> str(a) '1.9' >>> str((a,a)) '(1.9, 1.9)' >>> str([a,a]) '[1.9, 1.9]' >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506741&group_id=5470 From noreply@sourceforge.net Tue Jan 22 09:41:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 01:41:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-505427 ] socket module fails to build on HPUX10 Message-ID: Bugs item #505427, was opened at 2002-01-18 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Nobody/Anonymous (nobody) Summary: socket module fails to build on HPUX10 Initial Comment: On HPUX10, the variable h_errno is undeclared. Modules/socketmodule.c, line 1975: PyH_Err(h_errno); unless _XOPEN_SOURCE_EXTENDED is defined before netdb.h is included. Another option is to add an external declaration: #ifdef __hpux extern int h_errno; #endif ---------------------------------------------------------------------- >Comment By: Eddy De Greef (edg) Date: 2002-01-22 01:41 Message: Logged In: YES user_id=73597 On HPUX-10, the man page states the following: SYNOPSIS #include #include #include extern int h_errno; struct hostent *gethostent(void); int gethostent_r(struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyname(const char *name); int gethostbyname_r(const char *name, struct hostent *result, struct hostent_data *buffer); struct hostent *gethostbyaddr(const char *addr, int len, int type); _XOPEN_SOURCE_EXTENDED only struct hostent *gethostbyaddr(const void *addr, size_t len, int type); int gethostbyaddr_r(const char *addr, int len, int type, struct hostent *result, struct hostent_data *buffer); int sethostent(int stayopen); int sethostent_r(int stayopen, struct hostent_data *buffer); int endhostent(void); int endhostent_r(struct hostent_data *buffer); _XOPEN_SOURCE_EXTENDED only void sethostent(int stayopen); void endhostent(void); ... ERRORS If the name server is being used and gethostbyname() or gethostbyaddr() returns a NULL pointer, the external integer h_errno contains one of the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error. The local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY This is a non-recoverable error. NO_ADDRESS The requested name is valid but does not have an IP address; this is not a temporary error. This means another type of request to the name server will result in an answer. If the name server is not being used, the value of h_errno may not be meaningful. /usr/include/netdb.h includes the following fragment: #ifdef _XOPEN_SOURCE_EXTENDED extern int h_errno; #endif So, although this is not mentioned in the man page, _XOPEN_SOURCE_EXTENDED must be defined to include the declaration. On HPUX11, the man pages says more or less the same, but adds the following: WARNINGS Programs that use the interfaces described in this manpage cannot be linked statically because the implementations of these functions employ dynamic loading and linking of shared objects at run time. h_errno is referenced as an extern int for single thread applications and is defined as function call macro for multithreaded applications in file /usr/include/netdb.h. Applications that reference h_errno need to include /usr/include/netdb.h. /usr/include/netdb.h contains the following: /* * Error return codes from gethostbyname() and gethostbyaddr() */ #ifndef h_ERRNO_KT_DEFINED #define h_ERRNO_KT_DEFINED #ifdef _REENTRANT #ifdef _PROTOTYPES /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(void); /* 64 bit: add _PROTOTYPES */ #else /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ extern int *__h_errno(); #endif /* _PROTOTYPES */ /* 64 bit: add _PROTOTYPES */ #define h_errno (*__h_errno()) #else /* _REENTRANT */ extern int h_errno; #endif /* REENTRANT */ #endif /* ! h_ERRNO_KT_DEFINED */ #endif /* _NETDB_INCLUDED */ So, the only safe way to get things working on HPUX-10 and HPUX-11 is to define _XOPEN_SOURCE_EXTENDED before netdb.h is included. The hardcoded declaration I mentioned before isn't safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:09 Message: Logged In: YES user_id=21627 s/HPUX/HPUX11/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:09 Message: Logged In: YES user_id=21627 Does the second version of your patch also work on HPUX? Can you point to official documentation on that matter? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505427&group_id=5470 From noreply@sourceforge.net Tue Jan 22 19:34:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 11:34:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-507125 ] FTPLIB still missing "PASV" by default Message-ID: Bugs item #507125, was opened at 2002-01-22 11:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507125&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: FTPLIB still missing "PASV" by default Initial Comment: According to "Python Library Reference", by default "ftplib" uses PASSIVE mode. This is not the case for Python 2.2. In fact, the problem was already discussed more than a year ago, in http://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=226851. Nevertheless, the problem persists. The patch was not commited, it seems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507125&group_id=5470 From noreply@sourceforge.net Tue Jan 22 19:36:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 11:36:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-507125 ] FTPLIB still missing "PASV" by default Message-ID: Bugs item #507125, was opened at 2002-01-22 11:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507125&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) >Assigned to: Guido van Rossum (gvanrossum) >Summary: FTPLIB still missing "PASV" by default Initial Comment: According to "Python Library Reference", by default "ftplib" uses PASSIVE mode. This is not the case for Python 2.2. In fact, the problem was already discussed more than a year ago, in http://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=226851. Nevertheless, the problem persists. The patch was not commited, it seems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507125&group_id=5470 From noreply@sourceforge.net Tue Jan 22 19:58:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 11:58:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-507125 ] FTPLIB still missing "PASV" by default Message-ID: Bugs item #507125, was opened at 2002-01-22 11:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507125&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Guido van Rossum (gvanrossum) >Summary: FTPLIB still missing "PASV" by default Initial Comment: According to "Python Library Reference", by default "ftplib" uses PASSIVE mode. This is not the case for Python 2.2. In fact, the problem was already discussed more than a year ago, in http://sourceforge.net/tracker/? group_id=5470&atid=105470&func=detail&aid=226851. Nevertheless, the problem persists. The patch was not commited, it seems. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-22 11:58 Message: Logged In: YES user_id=6380 Our apologies. This is s duplicate of #495693. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507125&group_id=5470 From noreply@sourceforge.net Tue Jan 22 23:23:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 15:23:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-507262 ] GNU --option syntax not supported Message-ID: Bugs item #507262, was opened at 2002-01-22 15:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507262&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jari Aalto (jaalto) Assigned to: Nobody/Anonymous (nobody) Summary: GNU --option syntax not supported Initial Comment: It would be good if the python interpreter supported standard GNU --log style options as well. Jari //root@W2KPICASSO /usr/bin $ python -V Python 2.2 //root@W2KPICASSO /usr/bin $ python --help Unknown option: -- usage: python [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information. //root@W2KPICASSO /usr/bin $ python -h usage: python [option] ... [-c cmd | file | -] [arg] ... Options and arguments (and corresponding environment variables): -c cmd : program passed in as string (terminates option list) -d : debug output from parser (also PYTHONDEBUG=x) -E : ignore environment variables (such as PYTHONPATH) -h : print this help message and exit -i : inspect interactively after running script, (also PYTHONINSPECT=x) and force prompts, even if stdin does not appear to be a terminal -O : optimize generated bytecode (a tad; also PYTHONOPTIMIZE=x) -OO : remove doc-strings in addition to the -O optimizations -Q arg : division options: -Qold (default), -Qwarn, - Qwarnall, -Qnew -S : don't imply 'import site' on initialization -t : issue warnings about inconsistent tab usage (- tt: issue errors) -u : unbuffered binary stdout and stderr (also PYTHONUNBUFFERED=x) -U : Unicode literals: treats '...' literals like u'...' -v : verbose (trace import statements) (also PYTHONVERBOSE=x) -V : print the Python version number and exit -W arg : warning control (arg is action:message:category:module:lineno) -x : skip first line of source, allowing use of non-Unix forms of #!cmd file : program read from script file - : program read from stdin (default; interactive mode if a tty) arg ...: arguments passed to program in sys.argv[1:] Other environment variables: PYTHONSTARTUP: file executed on interactive startup (no default) PYTHONPATH : ':'-separated list of directories prefixed to the default module search path. The result is sys.path. PYTHONHOME : alternate directory (or :). The default module search path uses /pythonX.X. PYTHONCASEOK : ignore case in 'import' statements (Windows). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507262&group_id=5470 From noreply@sourceforge.net Wed Jan 23 04:28:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 20:28:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11 Message-ID: Bugs item #506349, was opened at 2002-01-21 01:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Harald Koschinski (astir) Assigned to: Anthony Baxter (anthonybaxter) Summary: Zope crashing with signal 11 Initial Comment: after switching to python 2.1.2 compiled with GC (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) the crashes are back again :-((((((((((((((((((((((( ------------------------------------------------------------------------------------- 2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11 2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11 2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11 2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan 21 09:30:43 2002: Aiieee! 6749 exited with error code: 11 ----------------------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-22 20:28 Message: Logged In: YES user_id=29957 This is a bug in the current Zope 2.4.3 release. Either upgrade to the current 2.4 branch of CVS, grab the current 2.5 beta, or else wait until 2.4.4 is out. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-21 02:23 Message: Logged In: YES user_id=29957 Which version of Zope are you running? Does it have the RestrictedCompiler fix? As far as I am aware, Zope 2.4 includes it's own version of the Compiler code, and the current release of 2.4 still has the stacksize bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-21 01:39 Message: Logged In: YES user_id=29957 Which version of Zope are you running? Does it have the RestrictedCompiler fix? As far as I am aware, Zope 2.4 includes it's own version of the Compiler code, and the current release of 2.4 still has the stacksize bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470 From noreply@sourceforge.net Wed Jan 23 04:29:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 20:29:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-497697 ] building shared modules Message-ID: Bugs item #497697, was opened at 2001-12-29 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 Category: Documentation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building shared modules Initial Comment: [ report from http://bugs.debian.org/121759, submitted by Jochen Voss ] I tried to follow the description in /usr/share/doc/python2.1/html/ext/dnt-type- methods.html and the following manual sections in order to build a C extension module for Python 2.1. The mechanism does not work as advertised in the manual. To reproduce the problem try the following mkdir bugdir cd bugdir touch testx1module.c touch testx2module.c Now create a file named "Setup" with the following three lines in it: == Setup starts at next line ======================= *shared* testx1 testx1module.c testx2 testx2module.c -DFISCH=Barsch == Setup ends at previous line ===================== The third line will cause the problem later. I think it is valid syntax, because .../ext/module-defn-example.html states Several compiler options are supported: [...] -Dname=value Define a macro Now we try whether it works: type cp /usr/lib/python2.1/config/Makefile.pre.in . make -f Makefile.pre.in boot make For me this gives the output gcc -fPIC -g -O2 -Wall -Wstrict-prototypes - I/usr/include/python2.1 -I/usr/include/python2.1 - DHAVE_CONFIG_H -c ././testx1module.c - o ./testx1module.o gcc -shared ./testx1module.o - o ./testx1module.so The bug is the following: file "testx2module.so" is not created. And in fact "grep testx Makefile" emits SHAREDMODS= ./testx1module$(SO) testx2 testx2module.c -DFISCH=Barsch ./testx1module.o: $(srcdir)/./testx1module.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/./testx1module.c -o ./testx1module.o ./testx1module$(SO): ./testx1module.o; $(LDSHARED) ./testx1module.o -o ./testx1module$(SO) The second line looks suspicious. I can work around this by putting the defines in a variable, but I think this should be fixed nevertheless. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-22 20:29 Message: Logged In: YES user_id=29957 I'm assuming this is either done, or out of date now? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:06 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:21 Message: Logged In: YES user_id=21627 It's a documentation bug. The Setup.in method of building extensions is not supported anymore; please use distutils. If you can provide patches to bring Makefile.pre.in into a state so that it works for extensions again, such a patch would be incorporated (unless it breaks other things); we will not actively look for a solution. I assume that the specific section of the documentation you've been looking at is the same as http://www.python.org/doc/current/ext/building-on-unix.html (i.e. section 3, not section 2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 From noreply@sourceforge.net Wed Jan 23 07:33:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 23:33:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-507394 ] non-string __doc__/new style class prob. Message-ID: Bugs item #507394, was opened at 2002-01-22 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507394&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: non-string __doc__/new style class prob. Initial Comment: I have some new style classes in one of my packages, and wanted to use something other than a string for their __doc__ attributes (a descriptor, actually -- I want to lazily look up some docs via introspection). Unfortunately, it looks like reading "type.__doc__" will return None unless the __doc__ attribute was a string at class creation time. This seems to be because the type.__doc__ property takes precedence, and it just checks the tp_doc slot in the type's vtable. As __doc__ wasn't a string, type_new() leaves tp_doc as NULL. I have attached a small test program to demonstrate the problem. Its output is as follows: OldClass.__doc__ = 'object=None type=OldClass' OldClass().__doc__ = 'object=OldClass instance type=OldClass' NewClass.__doc__ = None NewClass().__doc__ = 'object=NewClass instance type=NewClass' Ideally, NewClass.__doc__ would give a similar result to OldClass.__doc__. One way to fix this might be to get rid of the type.__doc__ property, and set __doc__ in the class dictionary from tp_doc (if it is non NULL) during PyType_Ready(). James Henstridge ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507394&group_id=5470 From noreply@sourceforge.net Wed Jan 23 07:52:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 23:52:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-506741 ] ugly floats using str() on tuples,lists Message-ID: Bugs item #506741, was opened at 2002-01-21 17:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506741&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Tim Wegener (twegener) Assigned to: Nobody/Anonymous (nobody) Summary: ugly floats using str() on tuples,lists Initial Comment: Python version 2.1.1 Using str() to make floats look pretty works for str(some_float_variable), but for str(tuple_of_floats) the output floats are still ugly. In Python 2.1.1: >>> a=1.9 >>> a 1.8999999999999999 >>> str(a) '1.9' >>> (a,a) (1.8999999999999999, 1.8999999999999999) >>> str((a,a)) '(1.8999999999999999, 1.8999999999999999)' >>> [a,a] [1.8999999999999999, 1.8999999999999999] >>> str([a,a]) '[1.8999999999999999, 1.8999999999999999]' >>> In Python 1.5.2 >>> a=1.9 >>> str(a) '1.9' >>> str((a,a)) '(1.9, 1.9)' >>> str([a,a]) '[1.9, 1.9]' >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-22 23:52 Message: Logged In: YES user_id=21627 This is not a bug. If you want to format objects in a certain non-standard way, you must write your own algorithm to do so. See pprint.py for an example. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506741&group_id=5470 From noreply@sourceforge.net Wed Jan 23 07:54:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 23:54:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-506545 ] Extending and Embedding Section 3 rework Message-ID: Bugs item #506545, was opened at 2002-01-21 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506545&group_id=5470 Category: Documentation Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Extending and Embedding Section 3 rework Initial Comment: This problem was reported on python-help... Most of what is in Section 3 of the Extending and Embedding manual is outdated. It still gives instructions about building extensions using Modules/Setup and Misc/Makefile.pre.in. This section should probably be reworked to make Distutils more prominent and remove all references to Makefile.pre.in, which isn't even distributed with Python anymore. Skip ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-22 23:54 Message: Logged In: YES user_id=21627 A patch for that problem is in http://sourceforge.net/tracker/?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506545&group_id=5470 From noreply@sourceforge.net Wed Jan 23 07:58:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 23:58:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-500115 ] "Extending" uses Makefile.pre.in Message-ID: Bugs item #500115, was opened at 2002-01-06 03:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500115&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: "Extending" uses Makefile.pre.in Initial Comment: The "Extending and Embedding the Python Interpreter" talks about Makefile.pre.in. Alas, that file is no longer available. I think it was a mistake to remove that file while the "Extending" document still refers to it; a year or two to switch over to the new distutils way of doing things would have been nice. Anyhow, http://www.python.org/doc/current/ext/building-on-unix.html should be updated. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-22 23:58 Message: Logged In: YES user_id=21627 Closed as a duplicate of #497695 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:04 Message: Logged In: YES user_id=21627 A patch for that is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500115&group_id=5470 From noreply@sourceforge.net Wed Jan 23 07:58:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Jan 2002 23:58:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-506545 ] Extending and Embedding Section 3 rework Message-ID: Bugs item #506545, was opened at 2002-01-21 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506545&group_id=5470 Category: Documentation Group: Python 2.2.1 candidate >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Extending and Embedding Section 3 rework Initial Comment: This problem was reported on python-help... Most of what is in Section 3 of the Extending and Embedding manual is outdated. It still gives instructions about building extensions using Modules/Setup and Misc/Makefile.pre.in. This section should probably be reworked to make Distutils more prominent and remove all references to Makefile.pre.in, which isn't even distributed with Python anymore. Skip ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-22 23:58 Message: Logged In: YES user_id=21627 Closed as a duplicate of #497695 and #500115. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-22 23:54 Message: Logged In: YES user_id=21627 A patch for that problem is in http://sourceforge.net/tracker/?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506545&group_id=5470 From noreply@sourceforge.net Wed Jan 23 08:05:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 00:05:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-506100 ] commands.getstatusoutput(): cmd.exe support Message-ID: Bugs item #506100, was opened at 2002-01-20 10:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Pierre Rouleau (pierre_rouleau) Assigned to: Nobody/Anonymous (nobody) >Summary: commands.getstatusoutput(): cmd.exe support Initial Comment: ##commands.getstatusoutput(): Does not support for DOS-type shells # ------------------------------------------------------------- # # Inside commands.py, the getstatusoutput() function is not capable of running a # DOS-type shell command. The current code assumes that the operating system # is running a Unix-type shell. # # The old code is: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text # I propose that we update that code to check the operating system and support # DOS-style shells (for DOS, NT, OS/2) with the following modified code: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os if os.name in ['nt', 'dos', 'os2'] : # use Dos style command shell for NT, DOS and OS/2 pipe = os.popen(cmd + ' 2>&1', 'r') else : # use Unix style for all others pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-23 00:05 Message: Logged In: YES user_id=21627 My first reaction to this was "Is DOS still supported"? Changing subject to mention cmd.exe (which is not a DOS application). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 From noreply@sourceforge.net Wed Jan 23 09:16:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 01:16:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-497697 ] building shared modules Message-ID: Bugs item #497697, was opened at 2001-12-29 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 Category: Documentation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building shared modules Initial Comment: [ report from http://bugs.debian.org/121759, submitted by Jochen Voss ] I tried to follow the description in /usr/share/doc/python2.1/html/ext/dnt-type- methods.html and the following manual sections in order to build a C extension module for Python 2.1. The mechanism does not work as advertised in the manual. To reproduce the problem try the following mkdir bugdir cd bugdir touch testx1module.c touch testx2module.c Now create a file named "Setup" with the following three lines in it: == Setup starts at next line ======================= *shared* testx1 testx1module.c testx2 testx2module.c -DFISCH=Barsch == Setup ends at previous line ===================== The third line will cause the problem later. I think it is valid syntax, because .../ext/module-defn-example.html states Several compiler options are supported: [...] -Dname=value Define a macro Now we try whether it works: type cp /usr/lib/python2.1/config/Makefile.pre.in . make -f Makefile.pre.in boot make For me this gives the output gcc -fPIC -g -O2 -Wall -Wstrict-prototypes - I/usr/include/python2.1 -I/usr/include/python2.1 - DHAVE_CONFIG_H -c ././testx1module.c - o ./testx1module.o gcc -shared ./testx1module.o - o ./testx1module.so The bug is the following: file "testx2module.so" is not created. And in fact "grep testx Makefile" emits SHAREDMODS= ./testx1module$(SO) testx2 testx2module.c -DFISCH=Barsch ./testx1module.o: $(srcdir)/./testx1module.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/./testx1module.c -o ./testx1module.o ./testx1module$(SO): ./testx1module.o; $(LDSHARED) ./testx1module.o -o ./testx1module$(SO) The second line looks suspicious. I can work around this by putting the defines in a variable, but I think this should be fixed nevertheless. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-23 01:16 Message: Logged In: YES user_id=21627 The documentation patch has not been considered, yet (unfortunately, it can take many months to review a patch). However, the original problem of this report (Makefile.pre.in does not work anymore) can be closed as 'won't fix'. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-22 20:29 Message: Logged In: YES user_id=29957 I'm assuming this is either done, or out of date now? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:06 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:21 Message: Logged In: YES user_id=21627 It's a documentation bug. The Setup.in method of building extensions is not supported anymore; please use distutils. If you can provide patches to bring Makefile.pre.in into a state so that it works for extensions again, such a patch would be incorporated (unless it breaks other things); we will not actively look for a solution. I assume that the specific section of the documentation you've been looking at is the same as http://www.python.org/doc/current/ext/building-on-unix.html (i.e. section 3, not section 2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 From noreply@sourceforge.net Wed Jan 23 09:22:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 01:22:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-497697 ] building shared modules Message-ID: Bugs item #497697, was opened at 2001-12-29 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 Category: Documentation Group: Python 2.1.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: building shared modules Initial Comment: [ report from http://bugs.debian.org/121759, submitted by Jochen Voss ] I tried to follow the description in /usr/share/doc/python2.1/html/ext/dnt-type- methods.html and the following manual sections in order to build a C extension module for Python 2.1. The mechanism does not work as advertised in the manual. To reproduce the problem try the following mkdir bugdir cd bugdir touch testx1module.c touch testx2module.c Now create a file named "Setup" with the following three lines in it: == Setup starts at next line ======================= *shared* testx1 testx1module.c testx2 testx2module.c -DFISCH=Barsch == Setup ends at previous line ===================== The third line will cause the problem later. I think it is valid syntax, because .../ext/module-defn-example.html states Several compiler options are supported: [...] -Dname=value Define a macro Now we try whether it works: type cp /usr/lib/python2.1/config/Makefile.pre.in . make -f Makefile.pre.in boot make For me this gives the output gcc -fPIC -g -O2 -Wall -Wstrict-prototypes - I/usr/include/python2.1 -I/usr/include/python2.1 - DHAVE_CONFIG_H -c ././testx1module.c - o ./testx1module.o gcc -shared ./testx1module.o - o ./testx1module.so The bug is the following: file "testx2module.so" is not created. And in fact "grep testx Makefile" emits SHAREDMODS= ./testx1module$(SO) testx2 testx2module.c -DFISCH=Barsch ./testx1module.o: $(srcdir)/./testx1module.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/./testx1module.c -o ./testx1module.o ./testx1module$(SO): ./testx1module.o; $(LDSHARED) ./testx1module.o -o ./testx1module$(SO) The second line looks suspicious. I can work around this by putting the defines in a variable, but I think this should be fixed nevertheless. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 01:22 Message: Logged In: YES user_id=29957 .. that was my thinking, yes. I've seen the documentation process for extensions bubbling along, but this particular problem seems to be a wontfix. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-23 01:16 Message: Logged In: YES user_id=21627 The documentation patch has not been considered, yet (unfortunately, it can take many months to review a patch). However, the original problem of this report (Makefile.pre.in does not work anymore) can be closed as 'won't fix'. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-22 20:29 Message: Logged In: YES user_id=29957 I'm assuming this is either done, or out of date now? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-08 14:06 Message: Logged In: YES user_id=21627 A patch for that problem is at http://sourceforge.net/tracker/index.php?func=detail&aid=500136&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-29 15:21 Message: Logged In: YES user_id=21627 It's a documentation bug. The Setup.in method of building extensions is not supported anymore; please use distutils. If you can provide patches to bring Makefile.pre.in into a state so that it works for extensions again, such a patch would be incorporated (unless it breaks other things); we will not actively look for a solution. I assume that the specific section of the documentation you've been looking at is the same as http://www.python.org/doc/current/ext/building-on-unix.html (i.e. section 3, not section 2). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497697&group_id=5470 From noreply@sourceforge.net Wed Jan 23 10:13:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 02:13:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Wed Jan 23 10:28:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 02:28:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None >Status: Open Resolution: Postponed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Michael Hudson (mwh) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 02:28 Message: Logged In: YES user_id=6656 Umm, I didn't mean to close this. Oh well. TBH, I'm tempted to close it again, with a resolution of "wont fix", but am open to persuasion. I'm not sure I can summon the motivation to add dependency tracking to distutils. And I don't like the hack I've attached to the report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:16 Message: Logged In: YES user_id=6380 I agree. Let's put this off until 2.3 (or maybe 2.2.1). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 04:39 Message: Logged In: YES user_id=6656 Here's an attempt. TBH, I'd be a bit nervous about fiddling with the build at this stage, but assigning to Guido to decide. I'd recommend assigning it back to me Pending/Later, and applying something like this early in 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 07:49 Message: Logged In: YES user_id=6656 OK, I'll try to get something concrete done in the next few days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 06:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 05:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 05:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 04:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Wed Jan 23 10:46:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 02:46:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-434944 ] setup.py - nonstandard paths Message-ID: Bugs item #434944, was opened at 2001-06-20 15:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 Category: Build Group: Feature Request >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Robert Minsk (rminsk) Assigned to: Michael Hudson (mwh) Summary: setup.py - nonstandard paths Initial Comment: In my build environment I have to ensure that the same version of each software package is available across many different platforms. To do this I compile code into a directory structure when the root path of /usr/tools/fw. So a tools like flex would result in files /usr/tools/fw/bin/flex, /usr/tools/fw/include/FlexLexer.h, /usr/tools/fw/lib/libfl.a, ... In the Python 2.1 build environment it does not seem that you can pass extra search paths too setup.py. I must either hack setup.py to look in /usr/tools/fw or manually add each module to Modules/Setup. It would be nice for setup.py to be able to take extra search paths. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 02:46 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 07:23 Message: Logged In: YES user_id=6656 Hello? I'm going to close this in a week if there's no further response. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:19 Message: Logged In: YES user_id=6656 Don't the -I & -L options to setup.py handle this? As in: ./python $(srcdir)/setup.py -I/usr/tools/fw/include \ -L/usr/tools/fw/lib ? I can't see how to arrange things to do this just by typing "make" -- is that what you're complaining about? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 From noreply@sourceforge.net Wed Jan 23 10:56:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 02:56:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 02:56 Message: Logged In: YES user_id=6656 I'm closing this, as it's abundantly clear it's not a Python problem. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-18 12:28 Message: Logged In: YES user_id=6656 Does the same workaround work? Is so, do all tests pass? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-12-18 12:23 Message: Logged In: YES user_id=88157 The same build failure is observed under Win98 for 2.2c1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:02 Message: Logged In: YES user_id=6656 FWIW, it seems building _socket statically solves the problem. This may suffice to for 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Wed Jan 23 11:01:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 03:01:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-493514 ] test_hotshot hangs under cygwin Message-ID: Bugs item #493514, was opened at 2001-12-14 15:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493514&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Michael Hudson (mwh) Summary: test_hotshot hangs under cygwin Initial Comment: It seems that test_hotshot simply hangs under cygwin (dll 1.3.6). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:01 Message: Logged In: YES user_id=6656 Closing for lack of follow up. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-15 06:11 Message: Logged In: YES user_id=6656 Works for me. More information? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493514&group_id=5470 From noreply@sourceforge.net Wed Jan 23 11:05:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 03:05:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Michael Hudson (mwh) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:05 Message: Logged In: YES user_id=6656 Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Wed Jan 23 12:18:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 04:18:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2002-01-23 04:18 Message: Logged In: YES user_id=52572 I'm just curious: how does "not a Python problem" get decided. If Python failed to build with VC++ on windows or GCC on linux I'm sure it would be considered a problem. BTW, really, I'm only curious; I'm not suggesting that Cygwin should be important to you! -Dave ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 02:56 Message: Logged In: YES user_id=6656 I'm closing this, as it's abundantly clear it's not a Python problem. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-18 12:28 Message: Logged In: YES user_id=6656 Does the same workaround work? Is so, do all tests pass? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-12-18 12:23 Message: Logged In: YES user_id=88157 The same build failure is observed under Win98 for 2.2c1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:02 Message: Logged In: YES user_id=6656 FWIW, it seems building _socket statically solves the problem. This may suffice to for 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Wed Jan 23 12:44:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 04:44:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-507477 ] Py_CompileString and tracebacks Message-ID: Bugs item #507477, was opened at 2002-01-23 04:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Krzysztof Zych (badpenguin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_CompileString and tracebacks Initial Comment: The API docs say, that when compiling a string with Py_Compilestring(code, filename, start), the filename param is used to construct the code object and may appear in tracebacks. Exceptions generated from these compiled objects evaluated with PyEval_EvalCode do not show this valuable description. This does not, somehow, apply when using Python's compile() and eval(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470 From noreply@sourceforge.net Wed Jan 23 12:51:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 04:51:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Michael Hudson (mwh) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2002-01-23 04:51 Message: Logged In: YES user_id=43607 I'm reopening this. I'm not sure you really understand the problem. Python -E doesn't do anything here. At the time the newly built module is imported (line 172 in setup.py in the current version 1.76), the value of sys.path is (in my environment) ['..', '/ufs/sjoerd/lib/my-python', '', '/ufs/sjoerd/lib/my-python', '/ufs/sjoerd/src/Python/dist/src/Lib', '/ufs/sjoerd/src/Python/dist/src/Lib/lib-tk', '/ufs/sjoerd/src/Python/dist/src/build.irix646/Modules', '/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.irix64-6.5-2.2', '/ufs/sjoerd/lib/python2.2/site-packages']. python -E will remove the second entry since that is the only one in my PYTHONPATH. (Note, I build in a subdirectory of the one where setup.py is located, hence the first entry.) However, an older version of the newly built module may well be in one of the other directories. The point is, when setup tries to import the newly built module, it should try *only* the build/lib.* directory *and nothing else*. Otherwise the check is not valid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:05 Message: Logged In: YES user_id=6656 Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Wed Jan 23 13:09:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 05:09:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: Works For Me Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Sjoerd Mullender (sjoerd) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 05:07 Message: Logged In: YES user_id=6656 Well, I was fairly sure I didn't understand the problem, that why I was asking questions a month ago. I still don't see a real problem; if /ufs/sjoerd/lib/my-python is not on the path, we can be pretty sure about all the others except maybe site-packages, and that's after the build directory anyway. Has this really caused you problems? Feel free to change the code in site.py to something you're happy with. If sf is being as tedious to you as it is to me, maybe we can hash this out in email. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2002-01-23 04:51 Message: Logged In: YES user_id=43607 I'm reopening this. I'm not sure you really understand the problem. Python -E doesn't do anything here. At the time the newly built module is imported (line 172 in setup.py in the current version 1.76), the value of sys.path is (in my environment) ['..', '/ufs/sjoerd/lib/my-python', '', '/ufs/sjoerd/lib/my-python', '/ufs/sjoerd/src/Python/dist/src/Lib', '/ufs/sjoerd/src/Python/dist/src/Lib/lib-tk', '/ufs/sjoerd/src/Python/dist/src/build.irix646/Modules', '/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.irix64-6.5-2.2', '/ufs/sjoerd/lib/python2.2/site-packages']. python -E will remove the second entry since that is the only one in my PYTHONPATH. (Note, I build in a subdirectory of the one where setup.py is located, hence the first entry.) However, an older version of the newly built module may well be in one of the other directories. The point is, when setup tries to import the newly built module, it should try *only* the build/lib.* directory *and nothing else*. Otherwise the check is not valid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:05 Message: Logged In: YES user_id=6656 Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Wed Jan 23 13:15:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 05:15:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-489709 ] Building Fails under Cygwin Message-ID: Bugs item #489709, was opened at 2001-12-05 20:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 Category: Build Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Michael Hudson (mwh) Summary: Building Fails under Cygwin Initial Comment: Even after applying the h2py patch, building under Cygwin ends with the following error: building 'gdbm' extension gcc -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT - I. -I/cygdrive/e/Python-2.2b2/./Include - I/usr/local/include -IInclude/ -c /cygdrive/e/Python- 2.2b2/Modules/gdbmmodule.c -o build/temp.cygwin-1.3. 5-i686-2.2/gdbmmodule.o e:\buildpy\python.exe: *** unable to remap C:\cygnus\bin\cygssl.dll to same address as parent -- 0x1A7C0000 0 [main] python 1292 sync_with_child: child 1108 (0xF0) died before initialization with status code 0x1 25901 [main] python 1292 sync_with_child: *** child state child loading dlls error: Resource temporarily unavailable make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 05:15 Message: Logged In: YES user_id=6656 When it's not a Python problem . The problem lies in the cygwin libraries, and a fix is being worked on. It may take a while (depending on Jason's free time) before this is ready, and if it's not ready come release time, I'll look at linking _socket statically by default on cygwin. This probably isn't hard, but I don't know how to do it, and don't see a reason to learn just yet. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-01-23 04:18 Message: Logged In: YES user_id=52572 I'm just curious: how does "not a Python problem" get decided. If Python failed to build with VC++ on windows or GCC on linux I'm sure it would be considered a problem. BTW, really, I'm only curious; I'm not suggesting that Cygwin should be important to you! -Dave ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 02:56 Message: Logged In: YES user_id=6656 I'm closing this, as it's abundantly clear it's not a Python problem. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-18 12:28 Message: Logged In: YES user_id=6656 Does the same workaround work? Is so, do all tests pass? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-12-18 12:23 Message: Logged In: YES user_id=88157 The same build failure is observed under Win98 for 2.2c1. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 09:02 Message: Logged In: YES user_id=6656 FWIW, it seems building _socket statically solves the problem. This may suffice to for 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 05:13 Message: Logged In: YES user_id=6656 (sf keeps logging me out every ten minutes, grr) This is being hashed out on the cygwin list. It's unfortunately not obvious that it will be fixed in the 2.2 timeframe. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 07:16 Message: Logged In: YES user_id=6656 Hmm. Seems pretty similar to mine. I'll bug Jason Tishler and see if he knows anything about it. ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2001-12-06 07:12 Message: Logged In: YES user_id=52572 I'm using Win2K CYGWIN_NT-5.0 MOREPIE 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown And I've built and installed GCC 3.0.2, thought the Python build seems to use 2.95.x anyway. I am not on the cygwin mailing list, sorry ;-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-06 05:53 Message: Logged In: YES user_id=6656 Just to say that I'm seeing this too. What OS? I'm on NT4 SP6. Which cygwin? I'm [Administrator@MATHS-PC150 QUAKE]$ uname -a CYGWIN_NT-4.0 MATHS-PC150 1.3.6(0.47/3/2) 2001-12-03 15:41 i686 unknown I was actually assuming this was a cygwin bug. Are you on the cygwin mailing list? Maybe you could try raising it there? I would, but I *really* don't need another subscription to a high-volume mailing list right now. PS: can we add jason as a developer? then we can assign bugs to him . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=489709&group_id=5470 From noreply@sourceforge.net Wed Jan 23 13:45:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 05:45:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: Works For Me Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Sjoerd Mullender (sjoerd) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-23 05:45 Message: Logged In: YES user_id=11105 I have the impression that sjoerd wants a sys.path of ['/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.ir ix64-6.5-2.2'] before the module import is tried. Maybe something like (warning, untested!) oldpath = sys.path sys.path = self.build_dir try: __import__(ext.name) except ImportError: self.announce('WARNING: removing "%s" since importing it failed' % ext.name) sys.path = oldpath ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 05:07 Message: Logged In: YES user_id=6656 Well, I was fairly sure I didn't understand the problem, that why I was asking questions a month ago. I still don't see a real problem; if /ufs/sjoerd/lib/my-python is not on the path, we can be pretty sure about all the others except maybe site-packages, and that's after the build directory anyway. Has this really caused you problems? Feel free to change the code in site.py to something you're happy with. If sf is being as tedious to you as it is to me, maybe we can hash this out in email. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2002-01-23 04:51 Message: Logged In: YES user_id=43607 I'm reopening this. I'm not sure you really understand the problem. Python -E doesn't do anything here. At the time the newly built module is imported (line 172 in setup.py in the current version 1.76), the value of sys.path is (in my environment) ['..', '/ufs/sjoerd/lib/my-python', '', '/ufs/sjoerd/lib/my-python', '/ufs/sjoerd/src/Python/dist/src/Lib', '/ufs/sjoerd/src/Python/dist/src/Lib/lib-tk', '/ufs/sjoerd/src/Python/dist/src/build.irix646/Modules', '/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.irix64-6.5-2.2', '/ufs/sjoerd/lib/python2.2/site-packages']. python -E will remove the second entry since that is the only one in my PYTHONPATH. (Note, I build in a subdirectory of the one where setup.py is located, hence the first entry.) However, an older version of the newly built module may well be in one of the other directories. The point is, when setup tries to import the newly built module, it should try *only* the build/lib.* directory *and nothing else*. Otherwise the check is not valid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:05 Message: Logged In: YES user_id=6656 Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Wed Jan 23 14:43:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 06:43:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: Works For Me Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Sjoerd Mullender (sjoerd) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 06:43 Message: Logged In: YES user_id=6656 Don't think that can work (cPickle tries to import copy_reg, f'ex), but the attached might (using imp.load_dynamic() instead of __import__ so we can supply the filename). Does for me, anyway. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-23 05:45 Message: Logged In: YES user_id=11105 I have the impression that sjoerd wants a sys.path of ['/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.ir ix64-6.5-2.2'] before the module import is tried. Maybe something like (warning, untested!) oldpath = sys.path sys.path = self.build_dir try: __import__(ext.name) except ImportError: self.announce('WARNING: removing "%s" since importing it failed' % ext.name) sys.path = oldpath ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 05:07 Message: Logged In: YES user_id=6656 Well, I was fairly sure I didn't understand the problem, that why I was asking questions a month ago. I still don't see a real problem; if /ufs/sjoerd/lib/my-python is not on the path, we can be pretty sure about all the others except maybe site-packages, and that's after the build directory anyway. Has this really caused you problems? Feel free to change the code in site.py to something you're happy with. If sf is being as tedious to you as it is to me, maybe we can hash this out in email. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2002-01-23 04:51 Message: Logged In: YES user_id=43607 I'm reopening this. I'm not sure you really understand the problem. Python -E doesn't do anything here. At the time the newly built module is imported (line 172 in setup.py in the current version 1.76), the value of sys.path is (in my environment) ['..', '/ufs/sjoerd/lib/my-python', '', '/ufs/sjoerd/lib/my-python', '/ufs/sjoerd/src/Python/dist/src/Lib', '/ufs/sjoerd/src/Python/dist/src/Lib/lib-tk', '/ufs/sjoerd/src/Python/dist/src/build.irix646/Modules', '/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.irix64-6.5-2.2', '/ufs/sjoerd/lib/python2.2/site-packages']. python -E will remove the second entry since that is the only one in my PYTHONPATH. (Note, I build in a subdirectory of the one where setup.py is located, hence the first entry.) However, an older version of the newly built module may well be in one of the other directories. The point is, when setup tries to import the newly built module, it should try *only* the build/lib.* directory *and nothing else*. Otherwise the check is not valid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:05 Message: Logged In: YES user_id=6656 Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Wed Jan 23 15:09:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 07:09:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-433775 ] module build dir first in test import Message-ID: Bugs item #433775, was opened at 2001-06-16 10:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 Category: Build >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Michael Hudson (mwh) Summary: module build dir first in test import Initial Comment: This problem was found on a Linux (RedHat 7.1) system, but applies to all Unix systems. In the step "python setup.py build", after a shared module is built, setup checks whether it can import the module. During this test, the build directory should be at the beginning of sys.path to make sure you get the module that was actually built. Currently, the build directory is at the end. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 07:08 Message: Logged In: YES user_id=6656 Works for Sjoerd too, so I checked it in as revision 1.78 of setup.py (after doing a run of reindent.py and checking that in as revision 1.77). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 06:43 Message: Logged In: YES user_id=6656 Don't think that can work (cPickle tries to import copy_reg, f'ex), but the attached might (using imp.load_dynamic() instead of __import__ so we can supply the filename). Does for me, anyway. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-23 05:45 Message: Logged In: YES user_id=11105 I have the impression that sjoerd wants a sys.path of ['/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.ir ix64-6.5-2.2'] before the module import is tried. Maybe something like (warning, untested!) oldpath = sys.path sys.path = self.build_dir try: __import__(ext.name) except ImportError: self.announce('WARNING: removing "%s" since importing it failed' % ext.name) sys.path = oldpath ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 05:07 Message: Logged In: YES user_id=6656 Well, I was fairly sure I didn't understand the problem, that why I was asking questions a month ago. I still don't see a real problem; if /ufs/sjoerd/lib/my-python is not on the path, we can be pretty sure about all the others except maybe site-packages, and that's after the build directory anyway. Has this really caused you problems? Feel free to change the code in site.py to something you're happy with. If sf is being as tedious to you as it is to me, maybe we can hash this out in email. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2002-01-23 04:51 Message: Logged In: YES user_id=43607 I'm reopening this. I'm not sure you really understand the problem. Python -E doesn't do anything here. At the time the newly built module is imported (line 172 in setup.py in the current version 1.76), the value of sys.path is (in my environment) ['..', '/ufs/sjoerd/lib/my-python', '', '/ufs/sjoerd/lib/my-python', '/ufs/sjoerd/src/Python/dist/src/Lib', '/ufs/sjoerd/src/Python/dist/src/Lib/lib-tk', '/ufs/sjoerd/src/Python/dist/src/build.irix646/Modules', '/ufs/sjoerd/src/Python/dist/src/build.irix646/build/lib.irix64-6.5-2.2', '/ufs/sjoerd/lib/python2.2/site-packages']. python -E will remove the second entry since that is the only one in my PYTHONPATH. (Note, I build in a subdirectory of the one where setup.py is located, hence the first entry.) However, an older version of the newly built module may well be in one of the other directories. The point is, when setup tries to import the newly built module, it should try *only* the build/lib.* directory *and nothing else*. Otherwise the check is not valid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 03:05 Message: Logged In: YES user_id=6656 Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:32 Message: Logged In: YES user_id=6656 Um. Is this actually a problem now we have python -E? (this would be easy enough to fix, though, after I actually found the code that puts the build dir in sys.path -- it's in site.py, of all places). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-24 05:16 Message: Logged In: YES user_id=6656 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433775&group_id=5470 From noreply@sourceforge.net Wed Jan 23 15:22:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 07:22:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Wed Jan 23 15:54:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 07:54:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-496154 ] Typos in dynload_beos.c Message-ID: Bugs item #496154, was opened at 2001-12-22 11:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496154&group_id=5470 Category: Build Group: Python 2.2.1 candidate >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Perrego (mperrego) >Assigned to: Michael Hudson (mwh) Summary: Typos in dynload_beos.c Initial Comment: There are two typos in dynload_beos.c: Line 210 : PyOs_snprintf should be PyOS_snprintf (capital "S") Line 237 : PyOS_snprintf( buff, sizeof(buf) should be PyOS_snprintf( buff, sizeof(buff) (two "f"s) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 07:53 Message: Logged In: YES user_id=6656 Yikes! You're right of course; fixed in revisions 2.8 & 2.6.6.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496154&group_id=5470 From noreply@sourceforge.net Wed Jan 23 15:58:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 07:58:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-468120 ] setup.py assumes existence of /usr/local Message-ID: Bugs item #468120, was opened at 2001-10-04 16:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=468120&group_id=5470 >Category: Build Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Michael Hudson (mwh) Summary: setup.py assumes existence of /usr/local Initial Comment: /usr/local doesn't exist on Max OS X, so the lines in setup.py at the start of detect_modules should propbably have: if os.path.isdir('/usr/local/lib') and '/usr/local/lib' not in self.compilier.library_dirs: etc. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 07:58 Message: Logged In: YES user_id=6656 Aha! This was the bug I fixed as a side effect of other work but then couldn't find in the tracker. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-07 12:57 Message: Logged In: YES user_id=21627 Please give as much detail as possible. What is the exact text of the warning message? Can you guess what program is generating it? When I add a non-existing directory in my copy of setup.py, no disturbing warnings are produced. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-10-07 00:38 Message: Logged In: YES user_id=6405 It generates a warning, several lines long, for each compile command. Doesn't break, just makes the compile more verbose than necessary :) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-05 17:13 Message: Logged In: YES user_id=21627 Why is that a problem? What happens with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=468120&group_id=5470 From noreply@sourceforge.net Wed Jan 23 16:08:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 08:08:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-220993 ] Installation flaky with multiple installers, old versions Message-ID: Bugs item #220993, was opened at 2000-11-01 05:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) >Assigned to: Michael Hudson (mwh) Summary: Installation flaky with multiple installers, old versions Initial Comment: Installation tends to have problems when there are old installations present, especially when a different user is doing the new installation. In particular, it appears that the chmod() done in 'copy_file()' (as a result of the "install" command attempting to preserve the mode of files from the build tree) fails, because you can't chmod() a file owned by somebody else. Paul Dubois suggests that simply unlinking the target file before doing the copy should work. I think he's right, but need to think about it and test it a bit first. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-23 08:07 Message: Logged In: YES user_id=6656 I'll have a look at this, as I've already assigned some installation related bugs to myself. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-20 11:41 Message: Logged In: YES user_id=11375 I think unlinking first is the right thing to do, having just run into another problem that seems to be caused by this. Installing *.so files to an NFS partition messed up other people, I think because they had the *.so file loaded into memory and the kernel's VM got confused. (That's the theory, anyway.) Bumping up the priority as a reminder to myself... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 From noreply@sourceforge.net Wed Jan 23 21:29:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 13:29:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-507713 ] mem leak in imaplib Message-ID: Bugs item #507713, was opened at 2002-01-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507713&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Scott Blomquist (scottdb) Assigned to: Nobody/Anonymous (nobody) Summary: mem leak in imaplib Initial Comment: When run in a multithreaded environment, the imaplib will leak memory if not run with the -O option. Long running, multithreaded programs that we have which use the imaplib will run fine for a undefined period of time, then suddenly start to grow in size until they take as much mem as the system will give to them. Once they start to grow, they continue to grow at a pretty consistent rate. Specifically: If the -O option is not used, in the _log method starting on line 1024 in the imaplib class, the imaplib keeps the last 10 commands that are sent. def _log(line): # Keep log of last `_cmd_log_len' interactions for debugging. if len(_cmd_log) == _cmd_log_len: del _cmd_log[0] _cmd_log.append((time.time(), line)) Unfortunately, in a multithreaded environment, eventually the len of the list will become larger than the _cmd_log_len, and since the test is for equality, rather than greater-than-equal-to, once the len of the _cmd_log gets larger than _cmd_log_len, nothing will ever be removed from the _cmd_log, and the list will grow without bound. We added the following to test this hypothesis, we created a basic test which creates 40 threads. These threads sit in while 1 loops and create an imaplib and then issue the logout command. We also added the following debug to the method above: if len(_cmd_log) > 10: print 'command log len is:', len(_cmd_log) We started the test, which ran fine, without leaking, for about 10 minutes, and without printing anything out. Somewhere around ten minutes, the process started to grow in size rapidly, and at the same time, the debug started printing out, and the size of the _cmd_log list did indeed grow very large, very fast. We repeated the test and the same symptoms occured, this time after only 5 minutes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507713&group_id=5470 From noreply@sourceforge.net Thu Jan 24 01:14:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 17:14:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-506100 ] commands.getstatusoutput(): cmd.exe support Message-ID: Bugs item #506100, was opened at 2002-01-20 10:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Pierre Rouleau (pierre_rouleau) Assigned to: Nobody/Anonymous (nobody) Summary: commands.getstatusoutput(): cmd.exe support Initial Comment: ##commands.getstatusoutput(): Does not support for DOS-type shells # ------------------------------------------------------------- # # Inside commands.py, the getstatusoutput() function is not capable of running a # DOS-type shell command. The current code assumes that the operating system # is running a Unix-type shell. # # The old code is: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text # I propose that we update that code to check the operating system and support # DOS-style shells (for DOS, NT, OS/2) with the following modified code: def getstatusoutput(cmd): """Return (status, output) of executing cmd in a shell.""" import os if os.name in ['nt', 'dos', 'os2'] : # use Dos style command shell for NT, DOS and OS/2 pipe = os.popen(cmd + ' 2>&1', 'r') else : # use Unix style for all others pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text ---------------------------------------------------------------------- >Comment By: Pierre Rouleau (pierre_rouleau) Date: 2002-01-23 17:14 Message: Logged In: YES user_id=420631 The changed proposed is for DOS-type shells, not DOS itself (as far as I know pure MS-DOS or PC-DOS are not supported). But Win32 platforms are (NT, 2000, ...) and they use the same type of native command interpreter shell. With the proposed change getstatusoutput() works in those. cmd.exe is available in NT, 2000 and also in OS/2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-23 00:05 Message: Logged In: YES user_id=21627 My first reaction to this was "Is DOS still supported"? Changing subject to mention cmd.exe (which is not a DOS application). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506100&group_id=5470 From noreply@sourceforge.net Thu Jan 24 07:59:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Jan 2002 23:59:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Thu Jan 24 08:57:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 00:57:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Thu Jan 24 09:38:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 01:38:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-24 01:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Thu Jan 24 14:07:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 06:07:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-507962 ] tk.splitlist does not support Unicode Message-ID: Bugs item #507962, was opened at 2002-01-24 06:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507962&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Huening (huening) Assigned to: Nobody/Anonymous (nobody) Summary: tk.splitlist does not support Unicode Initial Comment: Exception in Tkinter when trying to 'get' the Unicode- items in a Listbox. Reason: tk.splitlist does not support Unicode. A simple example. This works, no problems at all: ---- from Tkinter import * root = Tk() class Demo: def __init__(self, root): self.f = Frame(root) self.f.pack() self.l = Listbox(self.f) self.l.pack() self.but = Button(self.f, text='Get them', command=self.hol) self.but.pack() self.label = Label(self.f, text = 'Hi') self.label.pack(pady=10) def hol(self): out = '' for x in self.l.get(0, 'end'): out = out + '%s ' % x prog.label.configure(text = out) if __name__ == '__main__': txt = 'Mühsam ernährt sich das Eichhörnchen' txt_list = txt.split() prog = Demo(root) for x in txt_list: prog.l.insert(END, x) root.mainloop() -------- But... when I change my input to txt = u'Mühsam ernährt sich das Eichhörnchen' or to txt = 'Mühsam ernährt sich das Eichhörnchen' txt = unicode(txt, 'Latin-1') the words show up in te Listbox, but I cannot retrieve them from the Listbox: Exception in Tkinter callback Traceback (most recent call last): File "c:\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__ return apply(self.func, args) File "C:\ALLESM~1\TK-PMW~1.PY", line 21, in hol for x in self.l.get(0,3): File "c:\python21\lib\lib-tk\Tkinter.py", line 2293, in get return self.tk.splitlist(self.tk.call( UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507962&group_id=5470 From noreply@sourceforge.net Thu Jan 24 14:20:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 06:20:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-448481 ] Missing .h files and compiler warnings Message-ID: Bugs item #448481, was opened at 2001-08-06 11:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jack Jansen (jackjansen) Summary: Missing .h files and compiler warnings Initial Comment: Attempted to build 2.2a1 on Mac OS X 10.0.4. Got a LOT of compiler warnings (mostly "function declaration not a prototype"), but make specifically stopped when trying the following: Python/dynload_next.c:30: header file 'mach-o/ rld.h' not found Python/dynload_next.c:51: undefined type, found `NXStream' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode make: *** [Python/dynload_next.o] Error 1 I can redirect all warnings and errors to a .txt file and e-mail it to anyone who might want to have a look. -John Buell ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 06:20 Message: Logged In: NO don't forget --with-dyld after ./configure to enable dynamic load see ./configure --help to have more information ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-08 09:19 Message: Logged In: NO make got a lot further this time: cc -u __dummy -u _PyMac_Error -framework System - framework Foundation -framework Carbon -o python \ Modules/python.o \ libpython2.2.a -lpthread -ldl /usr/bin/ld: can't create output file: python (Is a directory, errno = 21) make: *** [python] Error 1 Except for that bit about the output file. I'm wondering if anyone else is having that problem, or if it's unique to the way I set up my directories. I've got everything in / Users/jbuell/Documents/Python with the full cvs directories underneath that. -John Buell ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-08-08 08:19 Message: Logged In: YES user_id=45365 This should be fixed in the CVS repository as of this afternoon. Please let me know if there are more problems. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470 From noreply@sourceforge.net Thu Jan 24 14:34:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 06:34:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 06:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 01:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Thu Jan 24 19:35:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 11:35:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-505490 ] Improve I/O redirection to embedding app Message-ID: Bugs item #505490, was opened at 2002-01-18 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Stefan Franke (sfranke) Assigned to: Nobody/Anonymous (nobody) Summary: Improve I/O redirection to embedding app Initial Comment: When embedding Python into an existing application, you usually do two things (among others): 1. Make Python use your own memory allocation 2. Redirect its I/O to the embedding app While the former is very easy due to the excellent pymem.h interface, the latter is quite painful, since the interpreter uses stdin/out/err directly. The common workaround I found on c.l.p is providing your own file-like objects in an extension module and assign them to sys.stdout/err within the interpreter. This solution still has its problems (like getting errors while import site.py) I wish Python would encapsulate I/O in a similar way than its malloc interface, and in some way I would expect this from a language which is said to be designed for extending and embedding. Unluckily I'm not able to this myself. I started my first embedding project a few days ago and still miss the big picture about Python's C API. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 11:35 Message: Logged In: YES user_id=21627 What do you mean with "you don't get tracebacks"? The attached a.py prints the traceback into the redirected file just fine (with 2.2, on Solaris 8). Also, which other output do you have in mind? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-01-21 02:14 Message: Logged In: YES user_id=45365 Assigning to sys.stdout and friends is only half a solution: you don't get tracebacks and any other output produced by the C code. Unfortunately there is no platform-independent solution without getting rid of stdio completely. Fortunately there are platform-dependent solutions for many platforms. MacPython has a lowlevel hook to do this, for instance. Depending on your stdio implementation you may be able to hook into stdio on a low level. An alternative 90% solution is to do the sys.stdout assignment and add Python code to print your tracebacks and such. An example of such code can be found in Idle (or IDE, or PythonWin, or any other windowing Python IDE). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:26 Message: Logged In: YES user_id=21627 I don't think that assigning to sys.stdout etc. is a work-around; it is the proper solution. If you worry about site.py, you can set Py_NoSiteFlag (which may be a good idea in an embedded interpreter, anyway); if you then still need site.py, you can import it on your own. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470 From noreply@sourceforge.net Thu Jan 24 19:39:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 11:39:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-508100 ] telnetlib in debug mode Message-ID: Bugs item #508100, was opened at 2002-01-24 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508100&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cedric Moreau (c_moe) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib in debug mode Initial Comment: In telnetlib.py, in function process_rawq() the display of IAC mode options in debug mode isn't right: Actually: ... self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c)) ... self.msg('IAC %s %d', c == WILL and 'WILL' or 'WONT', ord(c)) Should be: ... self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(opt)) ... self.msg('IAC %s %d', c == WILL and 'WILL' or 'WONT', ord(opt)) ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508100&group_id=5470 From noreply@sourceforge.net Thu Jan 24 19:53:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 11:53:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 11:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 06:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 01:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Thu Jan 24 20:02:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 12:02:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile() coredumps Message-ID: Bugs item #506611, was opened at 2002-01-21 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sys.setprofile() coredumps Initial Comment: Verified in current CVS (also on Windows, but doubt the platform matters). It's not the call proper that coredumps, but an eval loop's later attempt to use a resulting NULL pointer. From c.l.py: """ From: rihad Sent: Monday, January 21, 2002 1:19 PM Subject: minor Python bugs Calling sys.setprofile() (with no args) makes the interpreter crash, and calling sys.settrace() with no args succeeds, even though it is documented to take 1 arg (tracefunc). And yes, my version is '2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)]' """ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 12:02 Message: Logged In: YES user_id=21627 It appears that this patches deals only with the setprofile problem, not with the settrace problem. Is that intentional? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-21 14:39 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem. The patch includes a test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 From noreply@sourceforge.net Thu Jan 24 20:24:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 12:24:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile() coredumps Message-ID: Bugs item #506611, was opened at 2002-01-21 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sys.setprofile() coredumps Initial Comment: Verified in current CVS (also on Windows, but doubt the platform matters). It's not the call proper that coredumps, but an eval loop's later attempt to use a resulting NULL pointer. From c.l.py: """ From: rihad Sent: Monday, January 21, 2002 1:19 PM Subject: minor Python bugs Calling sys.setprofile() (with no args) makes the interpreter crash, and calling sys.settrace() with no args succeeds, even though it is documented to take 1 arg (tracefunc). And yes, my version is '2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)]' """ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-24 12:24 Message: Logged In: YES user_id=33168 I didn't read the part that settrace was a problem. I can take a look at the settrace problem later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 12:02 Message: Logged In: YES user_id=21627 It appears that this patches deals only with the setprofile problem, not with the settrace problem. Is that intentional? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-21 14:39 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem. The patch includes a test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 From noreply@sourceforge.net Thu Jan 24 21:46:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 13:46:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile() coredumps Message-ID: Bugs item #506611, was opened at 2002-01-21 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sys.setprofile() coredumps Initial Comment: Verified in current CVS (also on Windows, but doubt the platform matters). It's not the call proper that coredumps, but an eval loop's later attempt to use a resulting NULL pointer. From c.l.py: """ From: rihad Sent: Monday, January 21, 2002 1:19 PM Subject: minor Python bugs Calling sys.setprofile() (with no args) makes the interpreter crash, and calling sys.settrace() with no args succeeds, even though it is documented to take 1 arg (tracefunc). And yes, my version is '2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)]' """ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-24 13:46 Message: Logged In: YES user_id=33168 What is the appropriate behaviour for settrace()? Currently, it is the same as settrace(None) which disables the trace function. So is the doc correct or is the code correct? I can supply another patch to doc/code for settrace() depending on which needs to be changed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-24 12:24 Message: Logged In: YES user_id=33168 I didn't read the part that settrace was a problem. I can take a look at the settrace problem later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 12:02 Message: Logged In: YES user_id=21627 It appears that this patches deals only with the setprofile problem, not with the settrace problem. Is that intentional? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-21 14:39 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem. The patch includes a test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506611&group_id=5470 From noreply@sourceforge.net Thu Jan 24 21:48:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 13:48:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-508157 ] urllib.urlopen results.readline is slow Message-ID: Bugs item #508157, was opened at 2002-01-24 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Keith Davidson (kbdavidson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen results.readline is slow Initial Comment: The socket file object underlying the return from urllib.urlopen() is opened without any buffering resulting in very slow performance of results.readline (). The specific problem is in the httplib.HTTPResponse constructor. It calls sock.makefile() with a 0 for the buffer size. Forcing the buffer size to 4096 results in the time for calling readline() on a 60K character line to go from 16 seconds to .27 seconds (there is other processing going on here but the magnitude of the difference is correct). I am using Python 2.0 so I can not submit a patch easily but the problem appears to still be present in the 2.2 source. The specific change is to change the 0 in sock.makefile() to 4096 or some other reasonable buffer size: class HTTPResponse: def __init__(self, sock, debuglevel=0): self.fp = sock.makefile('rb', 0) <= change to 4096 self.debuglevel = debuglevel ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470 From noreply@sourceforge.net Thu Jan 24 21:54:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 13:54:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-508157 ] urllib.urlopen results.readline is slow Message-ID: Bugs item #508157, was opened at 2002-01-24 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Keith Davidson (kbdavidson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen results.readline is slow Initial Comment: The socket file object underlying the return from urllib.urlopen() is opened without any buffering resulting in very slow performance of results.readline (). The specific problem is in the httplib.HTTPResponse constructor. It calls sock.makefile() with a 0 for the buffer size. Forcing the buffer size to 4096 results in the time for calling readline() on a 60K character line to go from 16 seconds to .27 seconds (there is other processing going on here but the magnitude of the difference is correct). I am using Python 2.0 so I can not submit a patch easily but the problem appears to still be present in the 2.2 source. The specific change is to change the 0 in sock.makefile() to 4096 or some other reasonable buffer size: class HTTPResponse: def __init__(self, sock, debuglevel=0): self.fp = sock.makefile('rb', 0) <= change to 4096 self.debuglevel = debuglevel ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 13:54 Message: Logged In: NO What platform? --Guido (not logged in) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470 From noreply@sourceforge.net Fri Jan 25 02:22:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 18:22:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-508263 ] complex() doesn't call __complex__ Message-ID: Bugs item #508263, was opened at 2002-01-24 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Nobody/Anonymous (nobody) Summary: complex() doesn't call __complex__ Initial Comment: It calls __float__ instead. It is the same in 2.2b+ from Nov 7 and the one I got from CVS just now. /Sverker Python 2.2+ (#1, Jan 25 2002, 03:54:26) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import comptest Traceback (most recent call last): File "", line 1, in ? File "comptest.py", line 6, in ? b = complex(a) AttributeError: Tst instance has no attribute '__float__' >>> [1]+ Stopped ./python nicosys [25] cat comptest.py class Tst: def __complex__(self): return self a = Tst() b = complex(a) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 From noreply@sourceforge.net Fri Jan 25 02:37:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 18:37:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-508269 ] 'true' division - perceived misnormer Message-ID: Bugs item #508269, was opened at 2002-01-24 18:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508269&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 'true' division - perceived misnormer Initial Comment: Documentation misnormer. In 5.6 Binary arithmetic operations, in the 3d paragraph it says about division: "The result is that of mathematical division with the 'floor' function applied to the result..." I think this is a misnormer. I would say the integer division is neither less or more "mathematical" than the floating point division. More correct would be to say that it is the quotient from the mathematical group division algorithm (if positive at least). Or say that "the result is that of mathematical real number division with the floor operator applied to the result." Also the name in the objects, "__truediv__", is a misnormer. It would be better to call it "__floatdiv__", if that is what it is intended to be. If this is an argument to not change the current division operator, so much the better, I would rather keep it as it is and add a new operator for the floating point coercive division instead. For one thing, it would keep it close to the main de facto industry standards, C and Ada comes to mind. Well I guess that discussion is long overdue.... just my 2 cents. Reference: In the Abstract Algebra course I had at the university a few years ago, there was something called the "division algorithm". It defined mathematically the quotient and remainder. This was defined in structures called "groups", which the mathematical (positive) integers is an example of. The real numbers and operators make up a 'field', but those are not more or less 'mathematical' than groups. Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508269&group_id=5470 From noreply@sourceforge.net Fri Jan 25 03:07:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Jan 2002 19:07:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-508269 ] 'true' division - perceived misnormer Message-ID: Bugs item #508269, was opened at 2002-01-24 18:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508269&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 'true' division - perceived misnormer Initial Comment: Documentation misnormer. In 5.6 Binary arithmetic operations, in the 3d paragraph it says about division: "The result is that of mathematical division with the 'floor' function applied to the result..." I think this is a misnormer. I would say the integer division is neither less or more "mathematical" than the floating point division. More correct would be to say that it is the quotient from the mathematical group division algorithm (if positive at least). Or say that "the result is that of mathematical real number division with the floor operator applied to the result." Also the name in the objects, "__truediv__", is a misnormer. It would be better to call it "__floatdiv__", if that is what it is intended to be. If this is an argument to not change the current division operator, so much the better, I would rather keep it as it is and add a new operator for the floating point coercive division instead. For one thing, it would keep it close to the main de facto industry standards, C and Ada comes to mind. Well I guess that discussion is long overdue.... just my 2 cents. Reference: In the Abstract Algebra course I had at the university a few years ago, there was something called the "division algorithm". It defined mathematically the quotient and remainder. This was defined in structures called "groups", which the mathematical (positive) integers is an example of. The real numbers and operators make up a 'field', but those are not more or less 'mathematical' than groups. Sverker ---------------------------------------------------------------------- >Comment By: Sverker Nilsson (svenil) Date: 2002-01-24 19:07 Message: Logged In: YES user_id=356603 Forget what I said about 'groups', after checking it turns out the integers are actually a 'commutative ring': http://www.math.niu.edu/~beachy/aaol/rings.html#5108 I passed that abstract algebra a few years ago but forgot already... My main point stands though, there is actually a mathematical theorem called the 'division algorithm for integers': http://www.math.niu.edu/~beachy/aaol/integers.html#1103 Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508269&group_id=5470 From noreply@sourceforge.net Fri Jan 25 09:47:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 01:47:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-508263 ] complex() doesn't call __complex__ Message-ID: Bugs item #508263, was opened at 2002-01-24 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Nobody/Anonymous (nobody) Summary: complex() doesn't call __complex__ Initial Comment: It calls __float__ instead. It is the same in 2.2b+ from Nov 7 and the one I got from CVS just now. /Sverker Python 2.2+ (#1, Jan 25 2002, 03:54:26) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import comptest Traceback (most recent call last): File "", line 1, in ? File "comptest.py", line 6, in ? b = complex(a) AttributeError: Tst instance has no attribute '__float__' >>> [1]+ Stopped ./python nicosys [25] cat comptest.py class Tst: def __complex__(self): return self a = Tst() b = complex(a) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-25 01:47 Message: Logged In: YES user_id=6656 Um. Why does __complex__ return self? It has to return a complex number, surely? complex() calls __complex__, which doesn't return a complex number, so it falls back to trying to convert it to a float (which would then be promoted to complex), but this fails. It's possible this is silly behaviour -- a non-complex-returning __complex__ method is surely a bug and should be flagged as such. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 From noreply@sourceforge.net Fri Jan 25 10:07:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 02:07:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-452144 ] How to install some stuff to /usr/sbin Message-ID: Bugs item #452144, was opened at 2001-08-17 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: Michael Hudson (mwh) Summary: How to install some stuff to /usr/sbin Initial Comment: I'd like behavior identical to "scripts" but want certain files to go to /usr/sbin instead of /usr/bin How can I accomplish this? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-25 02:07 Message: Logged In: YES user_id=6656 I've been thinking build scripts needs to get a little smarter anyway. Will look at this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470 From noreply@sourceforge.net Fri Jan 25 10:08:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 02:08:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC Message-ID: Bugs item #454030, was opened at 2001-08-21 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: distutils cannot link C++ code with GCC Initial Comment: It is mandatory to link C++ code against -lstdc++ -lm when creating an extension. distutils does not do this in 2.1.1 Here is a setup.py for Python CXX that works around the problem, but it would be better for distutils to understand enough about C++ to do the right thing. THen the code for other compilers could be added. But GCC is important enough to do first. You can get the CXX sources from http://sourceforge.net/projects/cxx/ from distutils.core import setup, Extension if os.name == 'posix': CXX_libraries = ['stdc++','m'] else: CXX_libraries = [] setup(name="pycxx_demo", version="1.0", ext_modules= [Extension( "example", sources = [ "Demo/example.cxx", "Demo/python.cxx", "Demo/range.cxx", "Demo/rangetest.cxx", "Src/cxx_extensions.cxx", "Src/cxxextensions.c", "Src/cxxsupport.cxx", "Src/IndirectPythonInterface.cxx" ], include_dirs = [ ".", "Demo" ], libraries = CXX_libraries ) ] ) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-25 02:08 Message: Logged In: YES user_id=6656 Is this the same problem as [ #413582 ] g++ must be called for c++ extensions ? Not a rhetorical question, I would like to know! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:50 Message: Logged In: YES user_id=6380 Nobody at PL understands distutils well enough to do this, so lowering the priority -- there's no way this will hold up the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 From noreply@sourceforge.net Fri Jan 25 10:14:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 02:14:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-480215 ] softspace confused in nested print Message-ID: Bugs item #480215, was opened at 2001-11-09 14:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: softspace confused in nested print Initial Comment: Adapted from a c.l.py report: class C: . def __str__(self): . print "a" . return "b" print C() The output is " a\nb\n" -- note the surprising leading space. This is because PRINT_ITEM forces softspace to 1 *before* converting the output item (so softspace is 1 when we get into __str__, despite that nothing yet has been written). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-25 02:14 Message: Logged In: YES user_id=6656 In my bid to reduce the number of unassigned bugs I say: so what? print is magical, maybe too magical, but I thought the consensus was that it's not worth changing. Having side-effects in __str__ methods is gross anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470 From noreply@sourceforge.net Fri Jan 25 10:36:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 02:36:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 02:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 11:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 06:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 01:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Fri Jan 25 10:41:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 02:41:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Nobody/Anonymous (nobody) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 02:41 Message: Logged In: YES user_id=436029 Fileupload config.h ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 02:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 11:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 06:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 01:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Fri Jan 25 12:20:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 04:20:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 02:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Walder (stefanwalder) >Assigned to: Martin v. Löwis (loewis) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 02:41 Message: Logged In: YES user_id=436029 Fileupload config.h ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 02:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 11:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 06:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 01:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 00:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-23 23:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 07:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Fri Jan 25 13:21:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 05:21:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-508437 ] urllib.urlopen results.readline is slow Message-ID: Bugs item #508437, was opened at 2002-01-25 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508437&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Keith Davidson (kbdavidson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen results.readline is slow Initial Comment: The socket file object underlying the return from urllib.urlopen() is opened without any buffering resulting in very slow performance of results.readline (). The specific problem is in the httplib.HTTPResponse constructor. It calls sock.makefile() with a 0 for the buffer size. Forcing the buffer size to 4096 results in the time for calling readline() on a 60K character line to go from 16 seconds to .27 seconds (there is other processing going on here but the magnitude of the difference is correct). I am using Python 2.0 so I can not submit a patch easily but the problem appears to still be present in the 2.2 source. The specific change is to change the 0 in sock.makefile() to 4096 or some other reasonable buffer size: class HTTPResponse: def __init__(self, sock, debuglevel=0): self.fp = sock.makefile('rb', 0) <= change to 4096 self.debuglevel = debuglevel ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508437&group_id=5470 From noreply@sourceforge.net Fri Jan 25 14:06:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 06:06:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-508269 ] 'true' division - perceived misnormer Message-ID: Bugs item #508269, was opened at 2002-01-24 18:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508269&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Sverker Nilsson (svenil) >Assigned to: Guido van Rossum (gvanrossum) Summary: 'true' division - perceived misnormer Initial Comment: Documentation misnormer. In 5.6 Binary arithmetic operations, in the 3d paragraph it says about division: "The result is that of mathematical division with the 'floor' function applied to the result..." I think this is a misnormer. I would say the integer division is neither less or more "mathematical" than the floating point division. More correct would be to say that it is the quotient from the mathematical group division algorithm (if positive at least). Or say that "the result is that of mathematical real number division with the floor operator applied to the result." Also the name in the objects, "__truediv__", is a misnormer. It would be better to call it "__floatdiv__", if that is what it is intended to be. If this is an argument to not change the current division operator, so much the better, I would rather keep it as it is and add a new operator for the floating point coercive division instead. For one thing, it would keep it close to the main de facto industry standards, C and Ada comes to mind. Well I guess that discussion is long overdue.... just my 2 cents. Reference: In the Abstract Algebra course I had at the university a few years ago, there was something called the "division algorithm". It defined mathematically the quotient and remainder. This was defined in structures called "groups", which the mathematical (positive) integers is an example of. The real numbers and operators make up a 'field', but those are not more or less 'mathematical' than groups. Sverker ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-25 06:06 Message: Logged In: YES user_id=6380 We've spent months discussing this on usenix, and everything you say has been said many times. ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2002-01-24 19:07 Message: Logged In: YES user_id=356603 Forget what I said about 'groups', after checking it turns out the integers are actually a 'commutative ring': http://www.math.niu.edu/~beachy/aaol/rings.html#5108 I passed that abstract algebra a few years ago but forgot already... My main point stands though, there is actually a mathematical theorem called the 'division algorithm for integers': http://www.math.niu.edu/~beachy/aaol/integers.html#1103 Sverker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508269&group_id=5470 From noreply@sourceforge.net Fri Jan 25 14:09:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 06:09:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-480215 ] softspace confused in nested print Message-ID: Bugs item #480215, was opened at 2001-11-09 14:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: softspace confused in nested print Initial Comment: Adapted from a c.l.py report: class C: . def __str__(self): . print "a" . return "b" print C() The output is " a\nb\n" -- note the surprising leading space. This is because PRINT_ITEM forces softspace to 1 *before* converting the output item (so softspace is 1 when we get into __str__, despite that nothing yet has been written). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-25 06:09 Message: Logged In: YES user_id=6380 But there's an easy fix for this one, right? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 02:14 Message: Logged In: YES user_id=6656 In my bid to reduce the number of unassigned bugs I say: so what? print is magical, maybe too magical, but I thought the consensus was that it's not worth changing. Having side-effects in __str__ methods is gross anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470 From noreply@sourceforge.net Fri Jan 25 14:12:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 06:12:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-508157 ] urllib.urlopen results.readline is slow Message-ID: Bugs item #508157, was opened at 2002-01-24 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Keith Davidson (kbdavidson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen results.readline is slow Initial Comment: The socket file object underlying the return from urllib.urlopen() is opened without any buffering resulting in very slow performance of results.readline (). The specific problem is in the httplib.HTTPResponse constructor. It calls sock.makefile() with a 0 for the buffer size. Forcing the buffer size to 4096 results in the time for calling readline() on a 60K character line to go from 16 seconds to .27 seconds (there is other processing going on here but the magnitude of the difference is correct). I am using Python 2.0 so I can not submit a patch easily but the problem appears to still be present in the 2.2 source. The specific change is to change the 0 in sock.makefile() to 4096 or some other reasonable buffer size: class HTTPResponse: def __init__(self, sock, debuglevel=0): self.fp = sock.makefile('rb', 0) <= change to 4096 self.debuglevel = debuglevel ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-25 06:12 Message: Logged In: YES user_id=6380 I wonder why the author explicitly turned off buffering. There probably was a reason? Without knowing why, we can't just change it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 13:54 Message: Logged In: NO What platform? --Guido (not logged in) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470 From noreply@sourceforge.net Fri Jan 25 14:13:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 06:13:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-508437 ] urllib.urlopen results.readline is slow Message-ID: Bugs item #508437, was opened at 2002-01-25 05:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508437&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Keith Davidson (kbdavidson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen results.readline is slow Initial Comment: The socket file object underlying the return from urllib.urlopen() is opened without any buffering resulting in very slow performance of results.readline (). The specific problem is in the httplib.HTTPResponse constructor. It calls sock.makefile() with a 0 for the buffer size. Forcing the buffer size to 4096 results in the time for calling readline() on a 60K character line to go from 16 seconds to .27 seconds (there is other processing going on here but the magnitude of the difference is correct). I am using Python 2.0 so I can not submit a patch easily but the problem appears to still be present in the 2.2 source. The specific change is to change the 0 in sock.makefile() to 4096 or some other reasonable buffer size: class HTTPResponse: def __init__(self, sock, debuglevel=0): self.fp = sock.makefile('rb', 0) <= change to 4096 self.debuglevel = debuglevel ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508437&group_id=5470 From noreply@sourceforge.net Fri Jan 25 14:52:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 06:52:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-508476 ] exec does not pass on locals/globals Message-ID: Bugs item #508476, was opened at 2002-01-25 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508476&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: a.hofkamp (axhlkhb) Assigned to: Nobody/Anonymous (nobody) Summary: exec does not pass on locals/globals Initial Comment: Hello, The program shows the problem. -------------------- # spam.py # def myf(i): return i+1 def myg(i): return f(i)+10 print "Try to call myf() as f()" exec "print f(0)" in { 'g':myg, 'f':myf } print print "Try to call myg() as g()" print "and indirectly myf() as f()" exec "print g(0)" in { 'g':myg, 'f':myf } -------------------- We are trying to exec statements in a custom environment. A simple form works as expected (the f(0) call), a more complicated form fails, because the custom environment is not passed on downwards (in myg(), "f" is not known). In the 'real' program, the dictionary is dynamic, thus tricks like adding "f=myf" to the formal parameter list of myg cannot be done (not to mention that the custom environment is quite big). Apparently, it is not possible to execute functions in a custom environment. This behaviour severely limits the usefulness of exec. Until now, we fail to see the logic in this behaviour, therefore, we report it as a bug. The Python version we used is Python 1.5.2, but 2.1.1 also fails to execute the example. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508476&group_id=5470 From noreply@sourceforge.net Fri Jan 25 17:48:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 09:48:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-480215 ] softspace confused in nested print Message-ID: Bugs item #480215, was opened at 2001-11-09 14:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: softspace confused in nested print Initial Comment: Adapted from a c.l.py report: class C: . def __str__(self): . print "a" . return "b" print C() The output is " a\nb\n" -- note the surprising leading space. This is because PRINT_ITEM forces softspace to 1 *before* converting the output item (so softspace is 1 when we get into __str__, despite that nothing yet has been written). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-25 09:48 Message: Logged In: YES user_id=31435 It should be easier to fix than to argue about, yes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-25 06:09 Message: Logged In: YES user_id=6380 But there's an easy fix for this one, right? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 02:14 Message: Logged In: YES user_id=6656 In my bid to reduce the number of unassigned bugs I say: so what? print is magical, maybe too magical, but I thought the consensus was that it's not worth changing. Having side-effects in __str__ methods is gross anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470 From noreply@sourceforge.net Fri Jan 25 18:10:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 10:10:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-507394 ] non-string __doc__/new style class prob. Message-ID: Bugs item #507394, was opened at 2002-01-22 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507394&group_id=5470 Category: Type/class unification Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: non-string __doc__/new style class prob. Initial Comment: I have some new style classes in one of my packages, and wanted to use something other than a string for their __doc__ attributes (a descriptor, actually -- I want to lazily look up some docs via introspection). Unfortunately, it looks like reading "type.__doc__" will return None unless the __doc__ attribute was a string at class creation time. This seems to be because the type.__doc__ property takes precedence, and it just checks the tp_doc slot in the type's vtable. As __doc__ wasn't a string, type_new() leaves tp_doc as NULL. I have attached a small test program to demonstrate the problem. Its output is as follows: OldClass.__doc__ = 'object=None type=OldClass' OldClass().__doc__ = 'object=OldClass instance type=OldClass' NewClass.__doc__ = None NewClass().__doc__ = 'object=NewClass instance type=NewClass' Ideally, NewClass.__doc__ would give a similar result to OldClass.__doc__. One way to fix this might be to get rid of the type.__doc__ property, and set __doc__ in the class dictionary from tp_doc (if it is non NULL) during PyType_Ready(). James Henstridge ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-25 10:09 Message: Logged In: YES user_id=6380 This is a duplicate of #504343 Unicode docstrings and new style classes. Please see if the fix there works for you, and add a comment there to saif whether it does. Then I can check it in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507394&group_id=5470 From noreply@sourceforge.net Fri Jan 25 19:55:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 11:55:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-508476 ] exec does not pass on locals/globals Message-ID: Bugs item #508476, was opened at 2002-01-25 06:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508476&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: a.hofkamp (axhlkhb) Assigned to: Nobody/Anonymous (nobody) Summary: exec does not pass on locals/globals Initial Comment: Hello, The program shows the problem. -------------------- # spam.py # def myf(i): return i+1 def myg(i): return f(i)+10 print "Try to call myf() as f()" exec "print f(0)" in { 'g':myg, 'f':myf } print print "Try to call myg() as g()" print "and indirectly myf() as f()" exec "print g(0)" in { 'g':myg, 'f':myf } -------------------- We are trying to exec statements in a custom environment. A simple form works as expected (the f(0) call), a more complicated form fails, because the custom environment is not passed on downwards (in myg(), "f" is not known). In the 'real' program, the dictionary is dynamic, thus tricks like adding "f=myf" to the formal parameter list of myg cannot be done (not to mention that the custom environment is quite big). Apparently, it is not possible to execute functions in a custom environment. This behaviour severely limits the usefulness of exec. Until now, we fail to see the logic in this behaviour, therefore, we report it as a bug. The Python version we used is Python 1.5.2, but 2.1.1 also fails to execute the example. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-25 11:55 Message: Logged In: YES user_id=21627 This is not a bug. The set of globals for a piece of code is defined at the point when the code is compiled. So the dictionary you pass is only used to resolve names in the code, not to resolve names in functions called in the code. Suppose you do exec "urllib.localhost()" in {'socket':0} would you expect that socket resolves to 0 inside urllib.localhost? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508476&group_id=5470 From noreply@sourceforge.net Fri Jan 25 20:00:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 12:00:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-508263 ] complex() doesn't call __complex__ Message-ID: Bugs item #508263, was opened at 2002-01-24 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 candidate >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Nobody/Anonymous (nobody) Summary: complex() doesn't call __complex__ Initial Comment: It calls __float__ instead. It is the same in 2.2b+ from Nov 7 and the one I got from CVS just now. /Sverker Python 2.2+ (#1, Jan 25 2002, 03:54:26) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import comptest Traceback (most recent call last): File "", line 1, in ? File "comptest.py", line 6, in ? b = complex(a) AttributeError: Tst instance has no attribute '__float__' >>> [1]+ Stopped ./python nicosys [25] cat comptest.py class Tst: def __complex__(self): return self a = Tst() b = complex(a) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-25 12:00 Message: Logged In: YES user_id=21627 Michael is exactly right. Python *does* call the __complex__ method of the object, as demonstrated in the attached a.py. If the result is not a complex object, it will try to convert it to a float, and consider this float to be the real part of the result. This is what gives the error in your example. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 01:47 Message: Logged In: YES user_id=6656 Um. Why does __complex__ return self? It has to return a complex number, surely? complex() calls __complex__, which doesn't return a complex number, so it falls back to trying to convert it to a float (which would then be promoted to complex), but this fails. It's possible this is silly behaviour -- a non-complex-returning __complex__ method is surely a bug and should be flagged as such. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 From noreply@sourceforge.net Fri Jan 25 20:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 12:24:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-508665 ] Improvement of cgi.parse_qsl function Message-ID: Bugs item #508665, was opened at 2002-01-25 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508665&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement of cgi.parse_qsl function Initial Comment: I found the parsing function "parse_qsl" in the module "cgi" to have some flaws. Especially, empty names are allowed, even if empty values are explicitly disallowed. If the latter are allowed, "?name=" is accepted, while "?name" is ignored. Often you want to use links like "?logout" or "?help". This is not possible, even if empty values are explicitly allowed. Also, "strict parsing" objects to "?name=", while it ignores "?name=a=b=c". My improvement suggestion: ------------- use ---------- for name_value in pairs: if strict_parsing: nv = name_value.split('=', 2) if len(nv) != 2 or not len(nv[0]): raise ValueError, "bad query field: %s" % `name_value` else: nv = name_value.split('=', 1).append('') if not len(nv[0]): continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ----------- instead of -------- for name_value in pairs: nv = name_value.split('=', 1) if len(nv) != 2: if strict_parsing: raise ValueError, "bad query field: %s" % `name_value` continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508665&group_id=5470 From noreply@sourceforge.net Fri Jan 25 20:41:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 12:41:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-508665 ] Improvement of cgi.parse_qsl function Message-ID: Bugs item #508665, was opened at 2002-01-25 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508665&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Improvement of cgi.parse_qsl function Initial Comment: I found the parsing function "parse_qsl" in the module "cgi" to have some flaws. Especially, empty names are allowed, even if empty values are explicitly disallowed. If the latter are allowed, "?name=" is accepted, while "?name" is ignored. Often you want to use links like "?logout" or "?help". This is not possible, even if empty values are explicitly allowed. Also, "strict parsing" objects to "?name=", while it ignores "?name=a=b=c". My improvement suggestion: ------------- use ---------- for name_value in pairs: if strict_parsing: nv = name_value.split('=', 2) if len(nv) != 2 or not len(nv[0]): raise ValueError, "bad query field: %s" % `name_value` else: nv = name_value.split('=', 1).append('') if not len(nv[0]): continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ----------- instead of -------- for name_value in pairs: nv = name_value.split('=', 1) if len(nv) != 2: if strict_parsing: raise ValueError, "bad query field: %s" % `name_value` continue if len(nv[1]) or keep_blank_values: name = urllib.unquote(nv[0].replace('+', ' ')) value = urllib.unquote(nv[1].replace('+', ' ')) r.append((name, value)) ---------------------------------------------------------------------- >Comment By: Christoph Zwerschke (cito) Date: 2002-01-25 12:41 Message: Logged In: YES user_id=193957 -------- better use: ---------- 

for name_value in pairs:
    if strict_parsing:
        nv = name_value.split('=', 2)
        if len(nv) != 2 or not len(nv[0]):
            raise ValueError, "bad query field: %s" % 
`name_value`
    else:
        nv = name_value.split('=', 1)
        if not len(nv[0]):
            continue
        if len(nv) != 2:
            nv.append('')
    if len(nv[1]) or keep_blank_values:
        name = urllib.unquote(nv[0].replace('+', ' '))
        value = urllib.unquote(nv[1].replace('+', ' '))
        r.append((name, value))
---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508665&group_id=5470 From noreply@sourceforge.net Fri Jan 25 22:11:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 14:11:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-508700 ] import of C-extension causes crash Message-ID: Bugs item #508700, was opened at 2002-01-25 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keith Farmer (deoradh) Assigned to: Nobody/Anonymous (nobody) Summary: import of C-extension causes crash Initial Comment: PythonWin 2.1 (#15, Apr 16 2001, 18:25:49) Running on Win2k SP2 (both Pro and Server) Source code for the extension is at http://www.thuban.org/projects (see AstroMath). (Zip file uploaded) As suggested, I set up a couple threading/non- threading tests outside of Zope. Here are the results, and the sourcecode for the scripts. My guess now is that it's a Python error, or something that I don't know about how C-extensions behave under Python threads. AstroMathTest.py -- threaded, import outside of the thread run() method AstroMathTest-2.py -- threaded, import inside the thread run() method AstroMathTest-3.py -- unthreaded, import outside of the class AstroMathTest.py triggers an abnormal termination (when running under Zope, this crashes the server). The others execute normally. ---------- Keith J. Farmer kfarmer@thuban.org http://www.thuban.org D:\Users\kfarmer\Desktop>AstroMathTest.py abnormal program termination D:\Users\kfarmer\Desktop>AstroMathTest-2.py Period: 2448976 - 2448982 Body: 2 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449067 Body: 9 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449010 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed D:\Users\kfarmer\Desktop>AstroMathTest-3.py Period: 2448976 - 2449003 Body: 2 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2448982 Body: 6 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2449075 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 From noreply@sourceforge.net Fri Jan 25 23:41:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 15:41:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-508730 ] CGIHTTPServer execfile should save cwd Message-ID: Bugs item #508730, was opened at 2002-01-25 15:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508730&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dan Grassi (dgrassi) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer execfile should save cwd Initial Comment: In CGIHTTPServer when running a script via execfile the cwd is not saved and restored. If the executed script changes the cwd subsequent requests will fail because self.translate_path in SimpleHTTPServer relies on the cwd. One fix is to suround the execfile call with save_cwd = os.getcwd() and os.chdir(save_cwd) Here is the proposed fix starting at line 254: + save_cwd = os.getcwd() try: try: sys.argv = [scriptfile] if '=' not in decoded_query: sys.argv.append(decoded_query) sys.stdout = self.wfile sys.stdin = self.rfile execfile(scriptfile, {"__name__": "__main__"}) finally: + os.chdir(save_cwd) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508730&group_id=5470 From noreply@sourceforge.net Fri Jan 25 23:48:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 15:48:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-508730 ] CGIHTTPServer execfile should save cwd Message-ID: Bugs item #508730, was opened at 2002-01-25 15:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508730&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dan Grassi (dgrassi) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer execfile should save cwd Initial Comment: In CGIHTTPServer when running a script via execfile the cwd is not saved and restored. If the executed script changes the cwd subsequent requests will fail because self.translate_path in SimpleHTTPServer relies on the cwd. One fix is to suround the execfile call with save_cwd = os.getcwd() and os.chdir(save_cwd) Here is the proposed fix starting at line 254: + save_cwd = os.getcwd() try: try: sys.argv = [scriptfile] if '=' not in decoded_query: sys.argv.append(decoded_query) sys.stdout = self.wfile sys.stdin = self.rfile execfile(scriptfile, {"__name__": "__main__"}) finally: + os.chdir(save_cwd) ---------------------------------------------------------------------- >Comment By: Dan Grassi (dgrassi) Date: 2002-01-25 15:48 Message: Logged In: YES user_id=366473 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508730&group_id=5470 From noreply@sourceforge.net Fri Jan 25 23:55:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 15:55:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-508730 ] CGIHTTPServer execfile should save cwd Message-ID: Bugs item #508730, was opened at 2002-01-25 15:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508730&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dan Grassi (dgrassi) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer execfile should save cwd Initial Comment: In CGIHTTPServer when running a script via execfile the cwd is not saved and restored. If the executed script changes the cwd subsequent requests will fail because self.translate_path in SimpleHTTPServer relies on the cwd. One fix is to suround the execfile call with save_cwd = os.getcwd() and os.chdir(save_cwd) Here is the proposed fix starting at line 254: + save_cwd = os.getcwd() try: try: sys.argv = [scriptfile] if '=' not in decoded_query: sys.argv.append(decoded_query) sys.stdout = self.wfile sys.stdin = self.rfile execfile(scriptfile, {"__name__": "__main__"}) finally: + os.chdir(save_cwd) ---------------------------------------------------------------------- >Comment By: Dan Grassi (dgrassi) Date: 2002-01-25 15:55 Message: Logged In: YES user_id=366473 Here is the (hopefully) properly indented fix: + save_cwd = os.getcwd() try: try: sys.argv = [scriptfile] if '=' not in decoded_query: sys.argv.append(decoded_query) sys.stdout = self.wfile sys.stdin = self.rfile execfile(scriptfile, {"__name__": "__main__"}) finally: + os.chdir(save_cwd) ---------------------------------------------------------------------- Comment By: Dan Grassi (dgrassi) Date: 2002-01-25 15:48 Message: Logged In: YES user_id=366473 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508730&group_id=5470 From noreply@sourceforge.net Sat Jan 26 00:16:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 16:16:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-508263 ] complex() doesn't call __complex__ Message-ID: Bugs item #508263, was opened at 2002-01-24 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 candidate Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Nobody/Anonymous (nobody) Summary: complex() doesn't call __complex__ Initial Comment: It calls __float__ instead. It is the same in 2.2b+ from Nov 7 and the one I got from CVS just now. /Sverker Python 2.2+ (#1, Jan 25 2002, 03:54:26) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import comptest Traceback (most recent call last): File "", line 1, in ? File "comptest.py", line 6, in ? b = complex(a) AttributeError: Tst instance has no attribute '__float__' >>> [1]+ Stopped ./python nicosys [25] cat comptest.py class Tst: def __complex__(self): return self a = Tst() b = complex(a) ---------------------------------------------------------------------- >Comment By: Sverker Nilsson (svenil) Date: 2002-01-25 16:16 Message: Logged In: YES user_id=356603 The int() and float() functions worked even though I returned my own object. I would rather have the system allow it for complex() too. Otherwise the same check should be made for the other functions too. It just made me loose some time searching for a possible bug in my program because it was totally unexpected that it should call float() instead. I guess I can redefine complex and the others, but it would be more practical not to have to. It is not 'surely a bug' to return something else, in my case I return an expression tree to be evaluated and code-generated later. Seems to me the Python code is 'implementing policy', which I think is bad in general, making unnecessary checks restricting generality. If it was intended to catch bugs as implied in the previous response, it doesnt seems worthwile to restrict operations for all users only for occasional development bug catching, the bug would 'surely' be catched later anyway... Sverker ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-25 12:00 Message: Logged In: YES user_id=21627 Michael is exactly right. Python *does* call the __complex__ method of the object, as demonstrated in the attached a.py. If the result is not a complex object, it will try to convert it to a float, and consider this float to be the real part of the result. This is what gives the error in your example. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 01:47 Message: Logged In: YES user_id=6656 Um. Why does __complex__ return self? It has to return a complex number, surely? complex() calls __complex__, which doesn't return a complex number, so it falls back to trying to convert it to a float (which would then be promoted to complex), but this fails. It's possible this is silly behaviour -- a non-complex-returning __complex__ method is surely a bug and should be flagged as such. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 From noreply@sourceforge.net Sat Jan 26 03:44:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 19:44:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-508779 ] Disable flat namespace on MacOS X Message-ID: Bugs item #508779, was opened at 2002-01-25 19:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470 Category: Extension Modules Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Manoj Plakal (terabaap) Assigned to: Nobody/Anonymous (nobody) Summary: Disable flat namespace on MacOS X Initial Comment: Python: v2.2 OS: MacOS X 10.1 MacOS X 10.1 introduced two forms of linking for loadable modules: flat namespace and two-level namespace. Python 2.2 is set up to use flat namespace by default on OS X for building extension modules. I believe that this is a problem since it introduces spurious run-time linking errors when loading 2 or more modules that happen to have common symbols. The Linux and Windows implementations do not allow symbols within modules to clash with each other. This behavior also goes against expectations of C extension module writers. As a reproducible example, consider two dummy modules foo (foomodule.c) and bar (barmodule.c) both of which are built with a common file baz.c that contains some data variables. With the current Python 2.2 on OS X 10.1, only one of foo or bar can be imported, but NOT BOTH, into the same interpreter session. The files can be picked up from these URLs: http://yumpee.org/python/foomodule.c http://yumpee.org/python/barmodule.c http://yumpee.org/python/baz.c http://yumpee.org/python/setup.py If I run "python setup.py build" with Python 2.2 (built from the 2.2 source tarball) and then import foo followed by bar, I get an ImportError: "Failure linking new module" (from Python/dynload_next.c). If I add a call to NSLinkEditError() to print a more detailed error message, I see that the problem is multiple definitions of the data variables in baz.c. The above example works fine with Python 2.1 on Red Hat Linux 7.2 and Python 2.2a4 on Win98. If I then edit /usr/local/lib/python2.2/Makefile and change LDSHARED and BLDSHARED to not use flat_namespace: $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/local/bin/python2.2 -undefined error then the problem is solved and I can load both foo and bar without problems. More info and discussion is available at these URLs (also search groups.google.com for "comp.lang.python OS X import bug"): http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python http://mail.python.org/pipermail/pythonmac-sig/2002-January/004977.html It would be great to have this simple change be applied to Python 2.2.1. Manoj terabaap@yumpee.org ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470 From noreply@sourceforge.net Sat Jan 26 04:25:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 20:25:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-508779 ] Disable flat namespace on MacOS X Message-ID: Bugs item #508779, was opened at 2002-01-25 19:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470 Category: Extension Modules Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Manoj Plakal (terabaap) Assigned to: Nobody/Anonymous (nobody) Summary: Disable flat namespace on MacOS X Initial Comment: Python: v2.2 OS: MacOS X 10.1 MacOS X 10.1 introduced two forms of linking for loadable modules: flat namespace and two-level namespace. Python 2.2 is set up to use flat namespace by default on OS X for building extension modules. I believe that this is a problem since it introduces spurious run-time linking errors when loading 2 or more modules that happen to have common symbols. The Linux and Windows implementations do not allow symbols within modules to clash with each other. This behavior also goes against expectations of C extension module writers. As a reproducible example, consider two dummy modules foo (foomodule.c) and bar (barmodule.c) both of which are built with a common file baz.c that contains some data variables. With the current Python 2.2 on OS X 10.1, only one of foo or bar can be imported, but NOT BOTH, into the same interpreter session. The files can be picked up from these URLs: http://yumpee.org/python/foomodule.c http://yumpee.org/python/barmodule.c http://yumpee.org/python/baz.c http://yumpee.org/python/setup.py If I run "python setup.py build" with Python 2.2 (built from the 2.2 source tarball) and then import foo followed by bar, I get an ImportError: "Failure linking new module" (from Python/dynload_next.c). If I add a call to NSLinkEditError() to print a more detailed error message, I see that the problem is multiple definitions of the data variables in baz.c. The above example works fine with Python 2.1 on Red Hat Linux 7.2 and Python 2.2a4 on Win98. If I then edit /usr/local/lib/python2.2/Makefile and change LDSHARED and BLDSHARED to not use flat_namespace: $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/local/bin/python2.2 -undefined error then the problem is solved and I can load both foo and bar without problems. More info and discussion is available at these URLs (also search groups.google.com for "comp.lang.python OS X import bug"): http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python http://mail.python.org/pipermail/pythonmac-sig/2002-January/004977.html It would be great to have this simple change be applied to Python 2.2.1. Manoj terabaap@yumpee.org ---------------------------------------------------------------------- >Comment By: Manoj Plakal (terabaap) Date: 2002-01-25 20:25 Message: Logged In: YES user_id=150105 Another idea is to provide the option for flat or 2-level namespace when building extension modules on OS X, maybe as an extra flag passed to distutils.core.Extension or somewhere else ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470 From noreply@sourceforge.net Sat Jan 26 15:36:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 07:36:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-508263 ] complex() doesn't call __complex__ Message-ID: Bugs item #508263, was opened at 2002-01-24 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 candidate Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sverker Nilsson (svenil) >Assigned to: Guido van Rossum (gvanrossum) Summary: complex() doesn't call __complex__ Initial Comment: It calls __float__ instead. It is the same in 2.2b+ from Nov 7 and the one I got from CVS just now. /Sverker Python 2.2+ (#1, Jan 25 2002, 03:54:26) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import comptest Traceback (most recent call last): File "", line 1, in ? File "comptest.py", line 6, in ? b = complex(a) AttributeError: Tst instance has no attribute '__float__' >>> [1]+ Stopped ./python nicosys [25] cat comptest.py class Tst: def __complex__(self): return self a = Tst() b = complex(a) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-26 07:36 Message: Logged In: YES user_id=6656 The lang ref says: __complex__(self) __int__(self) __long__(self) __float__(self) Called to implement the built-in functions complex() int() long() and float() Should return a value of the appropriate type. I suppose that's only "should", not must, but I find the idea that after executing i = int(ob) i is not in integer repellent. Guido? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2002-01-25 16:16 Message: Logged In: YES user_id=356603 The int() and float() functions worked even though I returned my own object. I would rather have the system allow it for complex() too. Otherwise the same check should be made for the other functions too. It just made me loose some time searching for a possible bug in my program because it was totally unexpected that it should call float() instead. I guess I can redefine complex and the others, but it would be more practical not to have to. It is not 'surely a bug' to return something else, in my case I return an expression tree to be evaluated and code-generated later. Seems to me the Python code is 'implementing policy', which I think is bad in general, making unnecessary checks restricting generality. If it was intended to catch bugs as implied in the previous response, it doesnt seems worthwile to restrict operations for all users only for occasional development bug catching, the bug would 'surely' be catched later anyway... Sverker ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-25 12:00 Message: Logged In: YES user_id=21627 Michael is exactly right. Python *does* call the __complex__ method of the object, as demonstrated in the attached a.py. If the result is not a complex object, it will try to convert it to a float, and consider this float to be the real part of the result. This is what gives the error in your example. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 01:47 Message: Logged In: YES user_id=6656 Um. Why does __complex__ return self? It has to return a complex number, surely? complex() calls __complex__, which doesn't return a complex number, so it falls back to trying to convert it to a float (which would then be promoted to complex), but this fails. It's possible this is silly behaviour -- a non-complex-returning __complex__ method is surely a bug and should be flagged as such. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 From noreply@sourceforge.net Sat Jan 26 16:44:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 08:44:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-508263 ] complex() doesn't call __complex__ Message-ID: Bugs item #508263, was opened at 2002-01-24 18:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 candidate Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Guido van Rossum (gvanrossum) Summary: complex() doesn't call __complex__ Initial Comment: It calls __float__ instead. It is the same in 2.2b+ from Nov 7 and the one I got from CVS just now. /Sverker Python 2.2+ (#1, Jan 25 2002, 03:54:26) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import comptest Traceback (most recent call last): File "", line 1, in ? File "comptest.py", line 6, in ? b = complex(a) AttributeError: Tst instance has no attribute '__float__' >>> [1]+ Stopped ./python nicosys [25] cat comptest.py class Tst: def __complex__(self): return self a = Tst() b = complex(a) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-26 08:44 Message: Logged In: NO Indeed. --Guido (who keeps getting logged out from SF) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-26 07:36 Message: Logged In: YES user_id=6656 The lang ref says: __complex__(self) __int__(self) __long__(self) __float__(self) Called to implement the built-in functions complex() int() long() and float() Should return a value of the appropriate type. I suppose that's only "should", not must, but I find the idea that after executing i = int(ob) i is not in integer repellent. Guido? ---------------------------------------------------------------------- Comment By: Sverker Nilsson (svenil) Date: 2002-01-25 16:16 Message: Logged In: YES user_id=356603 The int() and float() functions worked even though I returned my own object. I would rather have the system allow it for complex() too. Otherwise the same check should be made for the other functions too. It just made me loose some time searching for a possible bug in my program because it was totally unexpected that it should call float() instead. I guess I can redefine complex and the others, but it would be more practical not to have to. It is not 'surely a bug' to return something else, in my case I return an expression tree to be evaluated and code-generated later. Seems to me the Python code is 'implementing policy', which I think is bad in general, making unnecessary checks restricting generality. If it was intended to catch bugs as implied in the previous response, it doesnt seems worthwile to restrict operations for all users only for occasional development bug catching, the bug would 'surely' be catched later anyway... Sverker ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-25 12:00 Message: Logged In: YES user_id=21627 Michael is exactly right. Python *does* call the __complex__ method of the object, as demonstrated in the attached a.py. If the result is not a complex object, it will try to convert it to a float, and consider this float to be the real part of the result. This is what gives the error in your example. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 01:47 Message: Logged In: YES user_id=6656 Um. Why does __complex__ return self? It has to return a complex number, surely? complex() calls __complex__, which doesn't return a complex number, so it falls back to trying to convert it to a float (which would then be promoted to complex), but this fails. It's possible this is silly behaviour -- a non-complex-returning __complex__ method is surely a bug and should be flagged as such. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508263&group_id=5470 From noreply@sourceforge.net Sat Jan 26 19:05:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 11:05:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-508944 ] socket-module SSL is broken Message-ID: Bugs item #508944, was opened at 2002-01-26 11:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508944&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jon Ribbens (jribbens) Assigned to: Nobody/Anonymous (nobody) Summary: socket-module SSL is broken Initial Comment: If you set a socket to non-blocking and then try to call socket.ssl on it, it fails because you are doing all the setup and calling SSL_connect as an indivisible operation in the object constructor. So you can't catch SSL_ERROR_WANT_READ/WRITE and restart SSL_connect because there is no way from python to call SSL_connect. (Don't tell me not to set the socket non-blocking - I need to implement timeouts. And don't tell me to use alarm(), my program is multi-threaded.) For the same reason, there is no way in Python to write an SSL server. The only way to create an SSL object is socket.ssl and it is hardcoded to call SSL_connect, you can't call SSL_accept. Please can you make it so that a new function in the socket module creates a proper SSL object (that preferably has actual useful methods to set the options, etc) that is not connected in its constructor so that you can then call SSL_connect or SSL_accept. It could then also have a makefile method like socket objects which would implement read and write properly (i.e. catching and handling WANT_READ/WANT_WRITE/ZERO_RETURN). You could even then make it so that it has methods to set the various options that OpenSSL provides rather than hard-coding them in the SSLObject constructor. Umm, sorry if I sound tetchy but due to the complete lack of documentation of the socket SSL facilities I've just spent ages trying to work out why my program wasn't working, only to discover that it's not possible to get it working. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508944&group_id=5470 From noreply@sourceforge.net Sat Jan 26 20:05:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 12:05:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-505417 ] Dynamic loading bug on HPUX Message-ID: Bugs item #505417, was opened at 2002-01-18 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Eddy De Greef (edg) Assigned to: Martin v. Löwis (loewis) Summary: Dynamic loading bug on HPUX Initial Comment: When a shared library is found on HPUX, but the requested symbol cannot be found, the dynamic loading function returns a random pointer, causing a crash soon afterwards. Python/dynload_hpux.c, line 50: shl_findsym(&lib, funcname, TYPE_UNDEFINED, (void *) &p); I suggest initializing p to NULL explicitly or checking the return value of shl_findsym(): -1 is returned on error. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-26 12:05 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as dynload_hpux.c 2.7, ACKS 1.157. ---------------------------------------------------------------------- Comment By: Eddy De Greef (edg) Date: 2002-01-21 07:18 Message: Logged In: YES user_id=73597 The man page says: DIAGNOSTICS If a library cannot be loaded, shl_load() returns NULL and sets errno to indicate the error. All other functions return -1 on error and set errno. If shl_findsym() cannot find the indicated symbol, errno is set to zero. If shl_findsym() finds the indicated symbol but cannot resolve all the symbols it depends on, errno is set to ENOSYM. I've attached a patch (tested on HPUX10 and HPUX11). Apart from checking and returning a NULL pointer, it also unloads the shared library in case the symbol is not found. Without this unloading, the Python build process fails because it tries to remove a text file that is busy (and it's cleaner to unload the library anyhow in case of a failure). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:06 Message: Logged In: YES user_id=21627 Can you please refer us to online documentation for shl_findsym? Or betterm can you provide a tested patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505417&group_id=5470 From noreply@sourceforge.net Sat Jan 26 20:12:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 12:12:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-505453 ] bug in gc.get_referrers() Message-ID: Bugs item #505453, was opened at 2002-01-18 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Martin v. Löwis (loewis) Summary: bug in gc.get_referrers() Initial Comment: `get_referrers()' can return objects which are already garbage but which are in cycles and haven't been collected yet. That in itself is a bug, but there is something weirder: in my experiments it only returns *some* of those objects. Perhaps this is indicative of a deeper bug in gc.get_referrers()? Here is a transcript showing how get_referrers() returns not one referrer (which would be correct), nor three (which would be the behavior if it included all the cyclic garbage, but two: Python 2.2+ (#6, Jan 17 2002, 12:47:08) [GCC 3.0.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def __init__(self): ... self.x = 0 ... >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; refs = gc.get_referrers(a3) >>> len(refs) 2 >>> refs[0] {'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>} >>> refs[1] {'A': , 'a3': <__main__.A instance at 0x8156d6c>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{'a': <__main__.A instance at 0x8155d54>, 'x': 1, 'a3': <__main__.A instance at 0x8156d6c>}, {...}], '__doc__': None} Then in the same session I start again and this time call `gc.collect()' before calling `gc.get_referrers()', yielding the expected results: >>> del a3 >>> collect() 0 >>> a1=A() >>> a1.x=1 >>> a2=A() >>> a2.x=2 >>> a1.a=a2 >>> a2.a=a1 >>> a3=A() >>> a3.x=3 >>> a1.a3=a3 >>> del a1, a2; gc.collect(); refs = gc.get_referrers(a3) 4 >>> len(refs) 1 >>> refs[0] {'A': , 'a3': <__main__.A instance at 0x8155bec>, 'gc': , '__builtins__': , '__name__': '__main__', 'refs': [{...}], '__doc__': None} If nobody else is more inclined to do it, then please let me know and I will investigate this bug. Also note that I am submitting a patch for gcmodule.c which calls `collect_generations()' at the beginning of `get_referrers()'. I do not believe that patch should be allowed to close this bug, unless someone can explain the above anomaly. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-26 12:12 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as libgc.tex 1.10; ACKS 1.158. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-19 03:07 Message: Logged In: YES user_id=52562 loewis: Those are good points. Hm. The reason I consider it a bug is that it bit me. I was trying to analyze memory usage in my application, and I got some confusing results, and then finally I recognized one of the objects as a temporary that I had created and destroyed earlier. Of course, if I had thought explicitly about the question of "does `get_referrers()' include dead but not collected cyclical objects?" I would have known the answer correctly, but I didn't think about it and just acted as though things that get de-linked (given that they had no __del__ methods) are effectively gone forever. But you made very good points, so I suggest changing the documentation, something like this: Index: dist/src/Doc/lib/libgc.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libgc.tex,v retrieving revision 1.9 diff -u -d -r1.9 libgc.tex --- dist/src/Doc/lib/libgc.tex 2001/12/14 21:19:08 1.9 +++ dist/src/Doc/lib/libgc.tex 2002/01/19 10:40:31 @@ -83,6 +83,11 @@ function will only locate those containers which support garbage collection; extension types which do refer to other objects but do not support garbage collection will not be found. + +Note that objects which have already been dereferenced, but which +live in cycles and have not yet been collected by the garbage collector +can be listed among the resulting referrers. To get only currently live +objects, call \function{collect()} before calling \function{get_referrers()}. \versionadded{2.2} \end{funcdesc} ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-18 13:18 Message: Logged In: YES user_id=21627 I fail to see the bug. You may argue that the object is conceptually dead already. However: a) there are different ways to bring it back into life: activating DEBUG_SAVEALL may bring them back to life, or they may have references originating from an object with an __del__, which are put onto gc.garbage always. b) tracing all objects is desirable, since it will help to explain the reference counter, and may help detecting bugs in extension modules. c) always collecting is expensive. d) if the application wants to, it can always initiate a collection itself. e) Initiating a collection may call back into Python code, thus changing many references in unforeseeable ways; this is undesirable if you have managed to bring the interpreter into a state where you want to analyse it, and then the interpreter messes up everything by invoking a collection. Unless you bring forward arguments why your application cannot initiate a collection itself before invoking get_referrers, I'm tempted to close this report. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 12:50 Message: Logged In: YES user_id=52562 Whoops. The unexplained behavior is actually perfectly well explained -- only one of those objects *does* reference a3. I believe that patch "[ #505464 ] fix (??) bug in `gc.get_referrers()'" fixes this bug. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:50 Message: Logged In: YES user_id=52562 I submitted a patch: "[ #505464 ] fix (??) bug in `gc.get_referrers()'" which eliminates the symptoms. ---------------------------------------------------------------------- Comment By: Zooko Ozoko (zooko) Date: 2002-01-18 09:45 Message: Logged In: YES user_id=52562 By the way, you are welcome to add my account `zooko' to the techs list and assign the bug to me, in order to indicate that I should look into it. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505453&group_id=5470 From noreply@sourceforge.net Sat Jan 26 20:22:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 12:22:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-507962 ] tk.splitlist does not support Unicode Message-ID: Bugs item #507962, was opened at 2002-01-24 06:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507962&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Huening (huening) Assigned to: Nobody/Anonymous (nobody) Summary: tk.splitlist does not support Unicode Initial Comment: Exception in Tkinter when trying to 'get' the Unicode- items in a Listbox. Reason: tk.splitlist does not support Unicode. A simple example. This works, no problems at all: ---- from Tkinter import * root = Tk() class Demo: def __init__(self, root): self.f = Frame(root) self.f.pack() self.l = Listbox(self.f) self.l.pack() self.but = Button(self.f, text='Get them', command=self.hol) self.but.pack() self.label = Label(self.f, text = 'Hi') self.label.pack(pady=10) def hol(self): out = '' for x in self.l.get(0, 'end'): out = out + '%s ' % x prog.label.configure(text = out) if __name__ == '__main__': txt = 'Mühsam ernährt sich das Eichhörnchen' txt_list = txt.split() prog = Demo(root) for x in txt_list: prog.l.insert(END, x) root.mainloop() -------- But... when I change my input to txt = u'Mühsam ernährt sich das Eichhörnchen' or to txt = 'Mühsam ernährt sich das Eichhörnchen' txt = unicode(txt, 'Latin-1') the words show up in te Listbox, but I cannot retrieve them from the Listbox: Exception in Tkinter callback Traceback (most recent call last): File "c:\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__ return apply(self.func, args) File "C:\ALLESM~1\TK-PMW~1.PY", line 21, in hol for x in self.l.get(0,3): File "c:\python21\lib\lib-tk\Tkinter.py", line 2293, in get return self.tk.splitlist(self.tk.call( UnicodeError: ASCII encoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-26 12:22 Message: Logged In: YES user_id=21627 Thanks for the report. This is fixed in _tkinter.c 1.123. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507962&group_id=5470 From noreply@sourceforge.net Sun Jan 27 05:56:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 21:56:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-509074 ] Need paths for Rez/DeRez in OSX Makefile Message-ID: Bugs item #509074, was opened at 2002-01-26 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509074&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Manoj Plakal (terabaap) Assigned to: Jack Jansen (jackjansen) Summary: Need paths for Rez/DeRez in OSX Makefile Initial Comment: The CVS version of Python uses Rez and DeRez in directory dist/src/Mac/OSX/Makefile. These are tools that come on the Apple Developers CD and are usually installed into /Developer/Tools, not necessarily in $PATH. It would be good to have /Developer/Tools/{Rez/DeRez} as the default commands used in the Makefile. Manoj terabaap@yumpee.org ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509074&group_id=5470 From noreply@sourceforge.net Sun Jan 27 07:05:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Jan 2002 23:05:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-493183 ] FreeBSD/Python 2.1.1 Segmentation fault Message-ID: Bugs item #493183, was opened at 2001-12-13 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD/Python 2.1.1 Segmentation fault Initial Comment: This is Python 2.1.1 on FreeBSD 4.4-RELEASE/i386. I have a reproducible way to make Python 2.1.1 segfault here, but I'm not sure the best way to go about debugging it. I'll save you the gory details unless you request them, but basically I use a Python program called "tmda-inject" to send my e-mail. It's core dumping when fed this one particular message (mess1.txt), but not others. Further, Python 1.5.2, 2.0 and 2.2b2 on the same machine have no such trouble. It only appears with Python 2.1.1. I can also reproduce this problem a complately different machine also running FreeBSD 4.4 and Python 2.1.1, but not with other operating systems. The problem appears to be specifically with FreeBSD and Python 2.1.1. I've attached the "mess1.txt" e-mail message, and also python2.1.core. If you'd like to look at tmda-inject, it's part of my TMDA package available at http://sf.net/projects/tmda/. Let me know if I can do anything further. [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.1 cvs/tmda/dist/bin/tmda-inject Segmentation fault (core dumped) [jasonrm@nightshade jasonrm]$ cat mess1.txt | python1.5 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.0 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ cat mess1.txt | python2.2 cvs/tmda/dist/bin/tmda-inject [jasonrm@nightshade jasonrm]$ gdb /usr/local/bin/python2.1 python2.1.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... Core was generated by `python2.1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/strop.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/time.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/binascii.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/lib-dynload/sha.so...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/python2.1/site-packages/cdbmodule.so...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 (gdb) where #0 0x28177e0e in _thread_sys_fsync () from /usr/lib/libc_r.so.4 #1 0x2818ea24 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 #2 0x28179222 in vfprintf () from /usr/lib/libc_r.so.4 #3 0x28169f75 in sprintf () from /usr/lib/libc_r.so.4 #4 0x80934ae in _PyString_FormatLong () #5 0x8093d48 in PyString_Format () #6 0x807b868 in PyNumber_Remainder () #7 0x80556a2 in PyEval_EvalCode () #8 0x8058d95 in PyEval_CallObjectWithKeywords () #9 0x80574cd in PyEval_EvalCode () #10 0x8058d95 in PyEval_CallObjectWithKeywords () #11 0x80574cd in PyEval_EvalCode () #12 0x8058d95 in PyEval_CallObjectWithKeywords () #13 0x80574cd in PyEval_EvalCode () #14 0x8058d95 in PyEval_CallObjectWithKeywords () #15 0x80574cd in PyEval_EvalCode () #16 0x8058d95 in PyEval_CallObjectWithKeywords () #17 0x80574cd in PyEval_EvalCode () #18 0x8058d95 in PyEval_CallObjectWithKeywords () #19 0x80574cd in PyEval_EvalCode () #20 0x80548a8 in PyEval_EvalCode () #21 0x806d75d in PyRun_FileExFlags () #22 0x806d70e in PyRun_FileExFlags () #23 0x806d6de in PyRun_FileExFlags () #24 0x806cab0 in PyRun_SimpleFileExFlags () #25 0x806c5b0 in PyRun_AnyFileExFlags () #26 0x8051795 in Py_Main () #27 0x80511c2 in main () #28 0x8051111 in _start () (gdb) ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-26 23:05 Message: Logged In: YES user_id=85984 Just for the record, the python-cdb author and I were able to track down the memory corruption bug. This was fixed in version 0.32 of the module. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-02 13:43 Message: Logged In: NO Right. Bugs in 3rd party modules are very common causes of core dumps, and often there's very little that points to the culprit, because all they do is corrupt memory, placing a landmine for some other innocent code to step on. --Guido (can't log in here on Windows :-) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 12:06 Message: Logged In: YES user_id=85984 Here is something very strange. I can now reproduce the segfault nearly each time, not just with one particular message. I installed an extension module this morning and after that point things went bad in a hurry. The module is python-cdb (http://pilcrow.madison.wi.us/sw/python-cdb-0.22a.tar.gz) This module was also present in my Python2.1 installation. It appears that removing the cdbmodule.so from my site-packages directory, or not using it in my program clears up the segfault, but as soon as I put it back, Python goes right back to segfaulting. I guess I'll contact the python-cdb maintainer about this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-01-02 09:49 Message: Logged In: YES user_id=85984 This problem has crept up again for the second time now. This time with Python 2.2, and strangely I can't reproduce it with any other Python version. As was the case last time, the hexlify() function is what is causing the segfault. I've attached backtrace_python2.2.txt -- it looks a bit more verbose than previous backtraces. Does this tell us anything new, or is it still a mystery? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 09:06 Message: Logged In: YES user_id=85984 Well, this bug does have to do with Python if only in the configure scripts and such. There is something in Python 2.1.1 that is triggering this that isn't in Python 1.5.2, 2.0 or 2.2. I do agree though that the core of the problem is in FreeBSD, Python 2.1.1 is just bringing it to the surface. There is also some evidence that this problem is fixed in later FreeBSD releases. For example, I can't reproduce the problem on a 4.4-STABLE box (a couple months newer than my 4.4-RELEASE boxes). It would be interesting to see if this problem "dissapears" when I upgrade to 4.5-RELEASE next month. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-18 08:47 Message: Logged In: YES user_id=31435 No, don't do it for Python's sake -- there's no reason to believe this has anything to do with Python, but is an obscure bug in the FreeBSD libc (which *has* been triggered by non-Python apps too, such as mysql). So I predict you'll see it again; if you pursued it, it would be for the benefit of FreeBSD users. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-18 08:36 Message: Logged In: YES user_id=85984 Tim, if you want me to pursue the issue with a FreeBSD libc internist for the good of Python, I'll do so. But otherwise, I'll let this one go as I don't plan on using Python 2.1.1 any longer. There is no evidence that this problem exists with Python 2.2. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 14:46 Message: Logged In: YES user_id=31435 Note that the same kind of mysterious bug was reported against mysql on FreeBSD (I mentioned this several notes ago). There's really no evidence of a Python bug here. Find someone knowledgeable about libc internals on FreeBSD: that's where the evidence points. They may also be able to help you figure out why you're getting a mix of threaded and non-threaded libcs; I can't say whether that's a problem, but it sure doesn't look right. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:14 Message: Logged In: YES user_id=85984 I'd say just close it out and keep it in the back of your mind in case something similar pops up in the future. I'll do the same. The bug is obscure and easy to workaround anyway. Thanks for your help with this. At the very least it has been an educational experience for me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-17 14:10 Message: Logged In: YES user_id=6380 So do you want me to keep this open? I don't expect we'll find the answer. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-17 14:07 Message: Logged In: YES user_id=85984 Your prediction is correct: [root@nightshade Python-2.1.1]# ./python df Python 2.1.1 (#1, Dec 17 2001, 15:01:24) [GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4 Type "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 21:13 Message: Logged In: YES user_id=6380 Add these three lines to Py_Main() in Modules/main.c, after the line saying "PyCompilerFlags cf;": char buffer[120]; sprintf(buffer, "%.1lx", 223L); printf("%s\n", buffer); and rebuild Python. When you run Python, it should print "df" before the standard banner. If it crashes, we've proved that Python is not the cause of the problem. But I predict that it'll work. :-( ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 21:01 Message: Logged In: YES user_id=85984 As far as the standalone program, I'm not a C programmer, (I've become Python-dependent :-), but if you can give me an idea of what it should contain, I'll give it a try. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 20:23 Message: Logged In: YES user_id=6380 Sigh. I think it's a dead end. What about a stand-alone program? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 19:09 Message: Logged In: YES user_id=85984 Tim asked whather I can verify whether I'm mixing the threaded and non-threaded versions of libc. Is the following enough to tell? $ ldd /usr/local/src/Python-2.1.1/python /usr/local/src/Python-2.1.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x280ca000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28182000) libm.so.2 => /usr/lib/libm.so.2 (0x2818b000) libc.so.4 => /usr/lib/libc.so.4 (0x281a7000) libc is the non-threaded library, and libc_r is the threaded version, so it looks like they are being mixed, yes? However, my Python 2.0.1 also looks the same way, and I'm not having any problems with it. $ ldd /usr/local/src/Python-2.0.1/python /usr/local/src/Python-2.0.1/python: libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2816c000) libutil.so.3 => /usr/lib/libutil.so.3 (0x28224000) libm.so.2 => /usr/lib/libm.so.2 (0x2822d000) libc.so.4 => /usr/lib/libc.so.4 (0x28249000) Next, Guido asked me to check some local variables in that stack frame. See attached backtrace3.txt. And to answer your question, yes I built all the Python versions I'm testing myself. I even rebuilt 2.0.1 and 2.1.1 in the simplest manner to make sure I'm comparing them equally. (Just ./configure && make). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:47 Message: Logged In: YES user_id=31435 BTW, a google search on _thread_autoinit_dummy_decl turns up another FreeBSD bug report of a death deep in libc_r starting with a sprintf() call. It had to do with mysql, not with Python. The tracebacks in both cases look worthless to me, because (for example) _thread_autoinit_dummy_decl is an extern int in the FreeBSD source, not a function at all. This increases the suspicion that libc versions are getting mixed up (and that gdb is looking up addresses in "the wrong" libc). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 17:20 Message: Logged In: YES user_id=6380 OK, it's the second sprintf call in formatint. Can you check some local variables in that stack frame? I expect fmt to be "%.1lx", but would like to see that confirmed; x should be one of the values from your binary string: 206, 199, 166. Can you see which one? It would then be interesting to find out what a small C program with that same sprintf() does. Make sure that the C program is compiled and linked in exactly the same way as python. (What I do in such cases is I put the experimental statement in Python's main() and rebuild Python. :-) The build procedure of each Python version is somewhat different, and it's likely that each version picks slightly different compile/link options. Also, did you build all the Python versions you tried yourself? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-16 17:17 Message: Logged In: YES user_id=31435 The new backtrace is helpful (thanks!), but it just makes it harder to believe that Python is at fault. The segfault occurs four levels deep in system library functions, and from inspection there's nothing even remotely suspicious about the sprintf call that kicks it off. As Guido suggested, can you verify you're not mixing the threaded and non-threaded versions of libc? Short of that, you really need a FreeBSD libc author to help with this. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-16 15:26 Message: Logged In: YES user_id=85984 Alright, I rebuilt Python 2.1.1 with -g, so the gdb backtrace now contains some more information. I attached backtrace2.txt which is a backtrace of the program failing when calling the hexlify() function. I tried compiling with `--with-pydebug', but then I can't reproduce the core dump for some reason. As you mention, this could have something to do with FreeBSD's libc. However, does that explain why I only have this problem with 2.1.1? On the same system, Python 1.5.2, 2.0, and 2.2c1 compiled in the same manner (simply ./configure && gmake) don't produce a core dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-16 11:24 Message: Logged In: YES user_id=6380 See the repeated "(no debugging symbols found)..." in the gdb output? try recompiling with -g. I strongly suspect that the traceback is lying, and we're in fact not in PyString_AsStringAndSize() when we call sprintf -- there's no sprintf call in that function (I checked the 2.1.1 source) but there is one two static functions down, in string_repr(), which is indeed called when you pickle a string object. This would match the original gdb stacktrace you reported: there's no sprintf call in _PyString_FormatLong(), but there are two in the next static function, formatint(), and it does make sense that that function would be called by the %02x format. All this makes no sense, however, because I can see nothing wrong with the arguments to sprintf here! I've heard of problems on FreeBSD having to do with different (threaded and unthreaded?) versions of libc. Could that be the issue here? Can you rebuild Python 2.1.1 with debugg flags on? (./configure --with-pydebug should do it for 2.2; I don't recall if the 2.2.1 configure supports that though -- try --help first.) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 23:49 Message: Logged In: YES user_id=85984 The argument to hexlify() is 3 bytes of raw binary. It's simply an HMAC of '%d' % time.time() stored in binary. Any suggestions on how to visualize, analyze, or store this argument? There is something about it that Python really doesn't like. I even tried to pickle it, and that too made Python core dump (see attached backtrace_pickle.txt). Strangely, binascii.hexlify has no problem handling it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-15 17:18 Message: Logged In: YES user_id=6380 Very strange. You could try setting a breakpoint in PyString_Format. But I would first try to boil down the program to a smaller example. For example, figure out what the argument to hexlify() is, and see if you get the same crash when you call hexlify() on its own with that argument. I find it curious why the core dump is in _PyString_FormatLong(), since hexlify doesn't pass longs to the % operator -- it passes a tuple of small ints. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:50 Message: Logged In: YES user_id=85984 BTW, if you need access to a FreeBSD machine, Sourceforge's "Compile Farm" has one available. ssh to `cf.sourceforge.net' ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-15 16:47 Message: Logged In: YES user_id=85984 Alright, through print statements, I've been able to pinpoint exactly where the program is failing causing Python to core dump. It is when the following function is called: def hexlify(b): return "%02x"*len(b) % tuple(map(ord, b)) Ironically, I got this function from you Guido. :-) (http://groups.google.com/groups?hl=en&selm=3924E204.CE01CA0A%40python.org) I only have to replace the function body with: return "foo" and the program no longer core dumps. The difficult thing has been trying to reproduce this problem with a smaller piece of code. I've been trying for hours and can't do it. As I said in my original message, I've never had this problem before this particular message. Even though its contents look harmless, there is something there that is triggering this problem. It seems pretty complex to me. However, I can run Python from inside gdb and get the program to crash from there. I changed the program to open "mess1.txt" directly. Not being experienced with gdb though, I'm not sure what kind of "digging around" to do. Could you give me some direction here? I've attached "backtrace1.txt" as a starting point. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-13 21:25 Message: Logged In: YES user_id=6380 Thanks for all the info, but I'm afraid you're going to have to work harder. We don't have FreeBSD here, so your core file won't do us any good. Can you use gdb to get a traceback and do some more digging? (It would be best not to do this from the core file, but to run the program under gdb until it crashes -- that way the stacktrace is more reliable and you can do more digging around.) Also, it would be really helpful if you could boil this down to a smaller piece of Python code. Maybe you can put print statements in your Python program that give you an idea of which operation is failing. As it is, the problem is too hard to reproduce to be worth debugging. The sample message contains nothing objectionable, so I think this must be a matter of something the program does that reads or write a bad pointer, where the value of the bad pointer depends on what was previously on the stack or what is in some spot of the heap. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2001-12-13 21:13 Message: Logged In: YES user_id=85984 Oops, the core file was too large to upload (1.5MB). If you want to see it, you can download it at: http://www.mastaler.com/tmp/2001-12-13/python2.1.core ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493183&group_id=5470 From noreply@sourceforge.net Sun Jan 27 09:37:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 01:37:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-01-27 01:37 Message: Logged In: YES user_id=146903 I am posting some comments about this patch after my similar bug was closed as a duplicate: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=507394 I just tested the typeobject.c patch, and it doesn't work when using a descriptor as the __doc__ for an object (the descriptor itself is returned for class.__doc__ rather than the result of the tp_descr_get function). With the patch applied, the output of the program attached to the above mentioned bug is: OldClass.__doc__ = 'object=None type=OldClass' OldClass().__doc__ = 'object=OldClass instance type=OldClass' NewClass.__doc__ = <__main__.DocDescr object at 0x811ce34> NewClass().__doc__ = 'object=NewClass instance type=NewClass' The suggestion I gave in the other bug is to get rid of the type.__doc__ property/getset all together, and make PyType_Ready() set __doc__ in tp_dict based on the value of tp_doc. Is there any reason why this wouldn't work? (it would seem to give behaviour more consistant with old style classes, which would be good). I will look at producing a patch to do this shortly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 08:14 Message: Logged In: YES user_id=89016 This sound much better. With my current patch all the docstrings for the builltin types are gone, because int etc. never goes through typeobject.c/type_new(). I updated the patch to use Guido's method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-17 06:25 Message: Logged In: YES user_id=6380 Wouldn't it be easier to set the __doc__ attribute in tp_dict and be done with it? That's what classic classes do. The accessor should still be a bit special: it should be implemented as a property (in tp_getsets), and first look for __doc__ in tp_dict and fall back to tp_doc. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 06:19 Message: Logged In: YES user_id=89016 OK, I've attached the patch. Note that I had to change the return value of PyStructSequence_InitType from void to int. Introducing tp_docobject should provide backwards compatibility for C extensions that still want to use tp_doc as char *. If this is not relevant then we could switch to PyObject *tp_doc immediately, but this complicates initializing a static type structure. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 05:45 Message: Logged In: YES user_id=21627 Adding tp_docobject would work, although it may be somewhat hackish (why should we have this kind of redundancy). I'm not sure how you will convert that to the 8bit version, though: what encoding? If you use the default encoding, tp_doc will be sometimes set, sometimes it won't. In any case, I'd encourage you to produce a patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Sun Jan 27 10:10:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 02:10:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-504343 ] Unicode docstrings and new style classes Message-ID: Bugs item #504343, was opened at 2002-01-16 04:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode docstrings and new style classes Initial Comment: Unicode docstrings don't work with new style classes. With old style classes they work: ---- class foo: u"föö" class bar(object): u"bär" print repr(foo.__doc__) print repr(bar.__doc__) ---- This prints ---- u'f\xf6\xf6' None ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-01-27 02:10 Message: Logged In: YES user_id=146903 Put together a patch that gets rid of the type.__doc__ property, and sets __doc__ in PyType_Ready() (if appropriate). Seems to work okay in my tests and as a bonus, "print type.__doc__" actually prints documentation on using the type() function :) SF doesn't seem to give me a way to attach a patch to this bug, so I will paste a copy of the patch here (if it is mangled, email me at james@daa.com.au for a copy): --- Python-2.2/Objects/typeobject.c.orig Tue Dec 18 01:14:22 2001 +++ Python-2.2/Objects/typeobject.c Sun Jan 27 17:56:37 2002 @@ -8,7 +8,6 @@ static PyMemberDef type_members[] = { {"__basicsize__", T_INT, offsetof(PyTypeObject,tp_basicsize),READONLY}, {"__itemsize__", T_INT, offsetof(PyTypeObject, tp_itemsize), READONLY}, {"__flags__", T_LONG, offsetof(PyTypeObject, tp_flags), READONLY}, - {"__doc__", T_STRING, offsetof(PyTypeObject, tp_doc), READONLY}, {"__weakrefoffset__", T_LONG, offsetof(PyTypeObject, tp_weaklistoffset), READONLY}, {"__base__", T_OBJECT, offsetof(PyTypeObject, tp_base), READONLY}, @@ -1044,9 +1043,9 @@ type_new(PyTypeObject *metatype, PyObjec } /* Set tp_doc to a copy of dict['__doc__'], if the latter is there - and is a string (tp_doc is a char* -- can't copy a general object - into it). - XXX What if it's a Unicode string? Don't know -- this ignores it. + and is a string. Note that the tp_doc slot will only be used + by C code -- python code will use the version in tp_dict, so + it isn't that important that non string __doc__'s are ignored. */ { PyObject *doc = PyDict_GetItemString(dict, "__doc__"); @@ -2024,6 +2023,19 @@ PyType_Ready(PyTypeObject *type) inherit_slots(type, (PyTypeObject *)b); } + /* if the type dictionary doesn't contain a __doc__, set it from + the tp_doc slot. + */ + if (PyDict_GetItemString(type->tp_dict, "__doc__") == NULL) { + if (type->tp_doc != NULL) { + PyObject *doc = PyString_FromString(type->tp_doc); + PyDict_SetItemString(type->tp_dict, "__doc__", doc); + Py_DECREF(doc); + } else { + PyDict_SetItemString(type->tp_dict, "__doc__", Py_None); + } + } + /* Some more special stuff */ base = type->tp_base; if (base != NULL) { ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-01-27 01:37 Message: Logged In: YES user_id=146903 I am posting some comments about this patch after my similar bug was closed as a duplicate: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=507394 I just tested the typeobject.c patch, and it doesn't work when using a descriptor as the __doc__ for an object (the descriptor itself is returned for class.__doc__ rather than the result of the tp_descr_get function). With the patch applied, the output of the program attached to the above mentioned bug is: OldClass.__doc__ = 'object=None type=OldClass' OldClass().__doc__ = 'object=OldClass instance type=OldClass' NewClass.__doc__ = <__main__.DocDescr object at 0x811ce34> NewClass().__doc__ = 'object=NewClass instance type=NewClass' The suggestion I gave in the other bug is to get rid of the type.__doc__ property/getset all together, and make PyType_Ready() set __doc__ in tp_dict based on the value of tp_doc. Is there any reason why this wouldn't work? (it would seem to give behaviour more consistant with old style classes, which would be good). I will look at producing a patch to do this shortly. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 08:14 Message: Logged In: YES user_id=89016 This sound much better. With my current patch all the docstrings for the builltin types are gone, because int etc. never goes through typeobject.c/type_new(). I updated the patch to use Guido's method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-17 06:25 Message: Logged In: YES user_id=6380 Wouldn't it be easier to set the __doc__ attribute in tp_dict and be done with it? That's what classic classes do. The accessor should still be a bit special: it should be implemented as a property (in tp_getsets), and first look for __doc__ in tp_dict and fall back to tp_doc. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-17 06:19 Message: Logged In: YES user_id=89016 OK, I've attached the patch. Note that I had to change the return value of PyStructSequence_InitType from void to int. Introducing tp_docobject should provide backwards compatibility for C extensions that still want to use tp_doc as char *. If this is not relevant then we could switch to PyObject *tp_doc immediately, but this complicates initializing a static type structure. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-17 05:45 Message: Logged In: YES user_id=21627 Adding tp_docobject would work, although it may be somewhat hackish (why should we have this kind of redundancy). I'm not sure how you will convert that to the 8bit version, though: what encoding? If you use the default encoding, tp_doc will be sometimes set, sometimes it won't. In any case, I'd encourage you to produce a patch. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-01-16 05:03 Message: Logged In: YES user_id=89016 What we could do is add a new slot tp_docobject, that holds the doc object. Then type_members would include {"__doc__", T_OBJECT, offsetof(PyTypeObject, tp_docobject), READONLY}, tp_doc should be initialized with an 8bit version of tp_docobject (using the default encoding and error='ignore' if tp_docobject is unicode). Does this sound reasonably? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-16 04:18 Message: Logged In: YES user_id=21627 There is a good chance that is caused by the lines following XXX What if it's a Unicode string? Don't know -- this ignores it. in Objects/typeobject.c. :-) Would you like to investigate the options and propose a patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504343&group_id=5470 From noreply@sourceforge.net Sun Jan 27 11:22:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 03:22:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Sun Jan 27 11:30:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 03:30:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Sun Jan 27 11:42:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 03:42:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC Message-ID: Bugs item #454030, was opened at 2001-08-21 16:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: distutils cannot link C++ code with GCC Initial Comment: It is mandatory to link C++ code against -lstdc++ -lm when creating an extension. distutils does not do this in 2.1.1 Here is a setup.py for Python CXX that works around the problem, but it would be better for distutils to understand enough about C++ to do the right thing. THen the code for other compilers could be added. But GCC is important enough to do first. You can get the CXX sources from http://sourceforge.net/projects/cxx/ from distutils.core import setup, Extension if os.name == 'posix': CXX_libraries = ['stdc++','m'] else: CXX_libraries = [] setup(name="pycxx_demo", version="1.0", ext_modules= [Extension( "example", sources = [ "Demo/example.cxx", "Demo/python.cxx", "Demo/range.cxx", "Demo/rangetest.cxx", "Src/cxx_extensions.cxx", "Src/cxxextensions.c", "Src/cxxsupport.cxx", "Src/IndirectPythonInterface.cxx" ], include_dirs = [ ".", "Demo" ], libraries = CXX_libraries ) ] ) ---------------------------------------------------------------------- >Comment By: Barry Alan Scott (barry-scott) Date: 2002-01-27 03:42 Message: Logged In: YES user_id=28665 Yes using G++ is another way to solve this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-25 02:08 Message: Logged In: YES user_id=6656 Is this the same problem as [ #413582 ] g++ must be called for c++ extensions ? Not a rhetorical question, I would like to know! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-06 13:50 Message: Logged In: YES user_id=6380 Nobody at PL understands distutils well enough to do this, so lowering the priority -- there's no way this will hold up the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470 From noreply@sourceforge.net Sun Jan 27 12:07:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 04:07:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Sun Jan 27 16:32:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 08:32:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Sun Jan 27 17:10:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 09:10:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-509215 ] formatting error api/iterator.html Message-ID: Bugs item #509215, was opened at 2002-01-27 09:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509215&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: formatting error api/iterator.html Initial Comment: http://www.python.org/doc/current/api/iterator.html also erroneously includes the docs on the buffer protocol, which have apparently remained in LaTeX markup rather than getting translated to HTML. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509215&group_id=5470 From noreply@sourceforge.net Sun Jan 27 17:14:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 09:14:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-508779 ] Disable flat namespace on MacOS X Message-ID: Bugs item #508779, was opened at 2002-01-25 19:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470 Category: Extension Modules Group: Python 2.2.1 candidate Status: Open Resolution: None >Priority: 7 Submitted By: Manoj Plakal (terabaap) Assigned to: Nobody/Anonymous (nobody) Summary: Disable flat namespace on MacOS X Initial Comment: Python: v2.2 OS: MacOS X 10.1 MacOS X 10.1 introduced two forms of linking for loadable modules: flat namespace and two-level namespace. Python 2.2 is set up to use flat namespace by default on OS X for building extension modules. I believe that this is a problem since it introduces spurious run-time linking errors when loading 2 or more modules that happen to have common symbols. The Linux and Windows implementations do not allow symbols within modules to clash with each other. This behavior also goes against expectations of C extension module writers. As a reproducible example, consider two dummy modules foo (foomodule.c) and bar (barmodule.c) both of which are built with a common file baz.c that contains some data variables. With the current Python 2.2 on OS X 10.1, only one of foo or bar can be imported, but NOT BOTH, into the same interpreter session. The files can be picked up from these URLs: http://yumpee.org/python/foomodule.c http://yumpee.org/python/barmodule.c http://yumpee.org/python/baz.c http://yumpee.org/python/setup.py If I run "python setup.py build" with Python 2.2 (built from the 2.2 source tarball) and then import foo followed by bar, I get an ImportError: "Failure linking new module" (from Python/dynload_next.c). If I add a call to NSLinkEditError() to print a more detailed error message, I see that the problem is multiple definitions of the data variables in baz.c. The above example works fine with Python 2.1 on Red Hat Linux 7.2 and Python 2.2a4 on Win98. If I then edit /usr/local/lib/python2.2/Makefile and change LDSHARED and BLDSHARED to not use flat_namespace: $(CC) $(LDFLAGS) -bundle -bundle_loader /usr/local/bin/python2.2 -undefined error then the problem is solved and I can load both foo and bar without problems. More info and discussion is available at these URLs (also search groups.google.com for "comp.lang.python OS X import bug"): http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python http://mail.python.org/pipermail/pythonmac-sig/2002-January/004977.html It would be great to have this simple change be applied to Python 2.2.1. Manoj terabaap@yumpee.org ---------------------------------------------------------------------- Comment By: Manoj Plakal (terabaap) Date: 2002-01-25 20:25 Message: Logged In: YES user_id=150105 Another idea is to provide the option for flat or 2-level namespace when building extension modules on OS X, maybe as an extra flag passed to distutils.core.Extension or somewhere else ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470 From noreply@sourceforge.net Sun Jan 27 18:17:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 10:17:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-27 10:17 Message: Logged In: YES user_id=31435 Laurent, the last component of your PATH: 'C:\Docs\Boulot\S\xe9minaireLORIA-jan2002\DemoCORBA' in not a Unicode string but contains a "funny character" (chr(0xe9)). It probably doesn't look funny to you , but the Unicode subsystem believes by default that non- Unicode strings are plain 7-bit ASCII, and \xe9 isn't legitimate under that belief. Because there are *some* Unicode strings in your PATH, the join attempt needs to convert all strings to Unicode, but it can't do it (the last path component isn't a valid encoding under the default belief). As a quick workaround, you could remove that entry from your PATH. Or you could set Python's belief about the default encoding to match your belief (it's impossible for Python to guess this, alas -- for all it knows your last path component was intended to be German or Navajo). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Sun Jan 27 20:06:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 12:06:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-509074 ] Need paths for Rez/DeRez in OSX Makefile Message-ID: Bugs item #509074, was opened at 2002-01-26 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509074&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Manoj Plakal (terabaap) Assigned to: Jack Jansen (jackjansen) Summary: Need paths for Rez/DeRez in OSX Makefile Initial Comment: The CVS version of Python uses Rez and DeRez in directory dist/src/Mac/OSX/Makefile. These are tools that come on the Apple Developers CD and are usually installed into /Developer/Tools, not necessarily in $PATH. It would be good to have /Developer/Tools/{Rez/DeRez} as the default commands used in the Makefile. Manoj terabaap@yumpee.org ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-01-27 12:06 Message: Logged In: YES user_id=45365 Fixed in Mac/OSX/Makefile rev. 1.8 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509074&group_id=5470 From noreply@sourceforge.net Sun Jan 27 20:24:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 12:24:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-509281 ] cheeseshop example shows wrong output Message-ID: Bugs item #509281, was opened at 2002-01-27 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509281&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ed James-Beckham (edj) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cheeseshop example shows wrong output Initial Comment: The cheeseshop example in 4.7.2 shows the output to be: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese shopkeeper : Michael Palin sketch : Cheese Shop Sketch when in fact, from the IDLE, one gets: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- shopkeeper : Michael Palin sketch : Cheese Shop Sketch client : John Cleese Experimenting, it seems that the first keyword argument ('client') always appears _last_ in the output. If this is, in fact, a bug in Python, please change the category appropriately and pass it on. Thanks, -edj ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509281&group_id=5470 From noreply@sourceforge.net Sun Jan 27 20:36:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 12:36:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-509281 ] cheeseshop example shows wrong output Message-ID: Bugs item #509281, was opened at 2002-01-27 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509281&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ed James-Beckham (edj) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cheeseshop example shows wrong output Initial Comment: The cheeseshop example in 4.7.2 shows the output to be: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese shopkeeper : Michael Palin sketch : Cheese Shop Sketch when in fact, from the IDLE, one gets: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- shopkeeper : Michael Palin sketch : Cheese Shop Sketch client : John Cleese Experimenting, it seems that the first keyword argument ('client') always appears _last_ in the output. If this is, in fact, a bug in Python, please change the category appropriately and pass it on. Thanks, -edj ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-27 12:36 Message: Logged In: YES user_id=31435 The order of entires in dict.keys() is not defined, and can change even across program runs. The docs could explain that, or sort dict.keys() before printing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509281&group_id=5470 From noreply@sourceforge.net Sun Jan 27 20:45:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 12:45:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-509288 ] package_dir paths not converted Message-ID: Bugs item #509288, was opened at 2002-01-27 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: package_dir paths not converted Initial Comment: If you supply a package_dir dictionary to setup(), as the most recent setup.py for Numeric does, the pathnames in this dictionary are used as-is, in stead of going through a URL-to-local-pathname-convention mapping, as all other pathnames do. I don't understand enough of the architecture to know where to do this conversion, so if someone else could have a look.... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 From noreply@sourceforge.net Sun Jan 27 21:35:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 13:35:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-505562 ] Summary: "BuildApplet can destory the source file on Mac OS X" Message-ID: Bugs item #505562, was opened at 2002-01-18 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505562&group_id=5470 Category: Macintosh Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) >Summary: Summary: "BuildApplet can destory the source file on Mac OS X" Initial Comment: If the name of the file dropped on BuildApplet is the right length, BuildApplet will work and then will delete the source file!!! For instance dropping a file named "Cvt cmm -> Igor data 2-0 long name.py" onto BuildApple first produces a working droplet with name: "Cvt cmm -> Igor data 2#7F2E4" and then the source file simply vanishes. It's really gone, too (or perhaps moved and renamed) -- a disk search doesn't turn it up anywhere. Making the file name significantly shorter causes everything to work normally. Making the file name significantly longer causes BuildApplet to exit immediately with no error message and nothing done. There seems to be a magic range of file name lengths that cause the source file to softly and silently vanish away. Configuration: - Mac OS X 10.1.2 - MacPython 2.1.1 configured for Carbon - I have only one disk partition, formatted as Mac OS Extended, with tons of free space. Further details available on request, but I hope the problem is easily reproducible. I tried it many times on my Mac and it always did the same thing. I doubt the contents of the source file is relevant, but if it is, I do have a copy (with a shorter name!). -- Russell ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-01-27 13:35 Message: Logged In: YES user_id=45365 This turns out to be a very serious problem in the way OSX converts long filenames to FSSpecs. I'm taking the discussion to pythonmac-sig (for starters). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505562&group_id=5470 From noreply@sourceforge.net Sun Jan 27 22:02:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 14:02:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 14:02 Message: Logged In: YES user_id=21627 I think the right solution would be to apply the file system encoding to each of the strings (either to the Unicode strings, producing byte strings, or vice versa). That, of course, would require that the file system encoding is exposed to the application. I have a PEP in mind titled "Unicode at system interfaces", which would include exposing the file system encoding, but I wanted to wait to see reactions (hopefully acceptance) of PEP 277 first. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-27 10:17 Message: Logged In: YES user_id=31435 Laurent, the last component of your PATH: 'C:\Docs\Boulot\S\xe9minaireLORIA-jan2002\DemoCORBA' in not a Unicode string but contains a "funny character" (chr(0xe9)). It probably doesn't look funny to you , but the Unicode subsystem believes by default that non- Unicode strings are plain 7-bit ASCII, and \xe9 isn't legitimate under that belief. Because there are *some* Unicode strings in your PATH, the join attempt needs to convert all strings to Unicode, but it can't do it (the last path component isn't a valid encoding under the default belief). As a quick workaround, you could remove that entry from your PATH. Or you could set Python's belief about the default encoding to match your belief (it's impossible for Python to guess this, alas -- for all it knows your last path component was intended to be German or Navajo). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Mon Jan 28 06:31:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Jan 2002 22:31:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 22:31 Message: Logged In: YES user_id=21627 Since this is msvccompiler, it should be safe to encode Unicode strings using the mbcs encoding. Laurent, can you please try the attached patch and report whether it solves the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 14:02 Message: Logged In: YES user_id=21627 I think the right solution would be to apply the file system encoding to each of the strings (either to the Unicode strings, producing byte strings, or vice versa). That, of course, would require that the file system encoding is exposed to the application. I have a PEP in mind titled "Unicode at system interfaces", which would include exposing the file system encoding, but I wanted to wait to see reactions (hopefully acceptance) of PEP 277 first. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-27 10:17 Message: Logged In: YES user_id=31435 Laurent, the last component of your PATH: 'C:\Docs\Boulot\S\xe9minaireLORIA-jan2002\DemoCORBA' in not a Unicode string but contains a "funny character" (chr(0xe9)). It probably doesn't look funny to you , but the Unicode subsystem believes by default that non- Unicode strings are plain 7-bit ASCII, and \xe9 isn't legitimate under that belief. Because there are *some* Unicode strings in your PATH, the join attempt needs to convert all strings to Unicode, but it can't do it (the last path component isn't a valid encoding under the default belief). As a quick workaround, you could remove that entry from your PATH. Or you could set Python's belief about the default encoding to match your belief (it's impossible for Python to guess this, alas -- for all it knows your last path component was intended to be German or Navajo). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Mon Jan 28 09:41:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 01:41:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-509288 ] package_dir paths not converted Message-ID: Bugs item #509288, was opened at 2002-01-27 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: package_dir paths not converted Initial Comment: If you supply a package_dir dictionary to setup(), as the most recent setup.py for Numeric does, the pathnames in this dictionary are used as-is, in stead of going through a URL-to-local-pathname-convention mapping, as all other pathnames do. I don't understand enough of the architecture to know where to do this conversion, so if someone else could have a look.... ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-28 01:41 Message: Logged In: YES user_id=11105 Jack, does this patch fix your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 From noreply@sourceforge.net Mon Jan 28 16:20:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 08:20:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-509288 ] package_dir paths not converted Message-ID: Bugs item #509288, was opened at 2002-01-27 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: package_dir paths not converted Initial Comment: If you supply a package_dir dictionary to setup(), as the most recent setup.py for Numeric does, the pathnames in this dictionary are used as-is, in stead of going through a URL-to-local-pathname-convention mapping, as all other pathnames do. I don't understand enough of the architecture to know where to do this conversion, so if someone else could have a look.... ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-28 08:20 Message: Logged In: YES user_id=11105 Oops, apparently package_dir can be None instead of beeing a dictionatry. Updated the patch (patch2.txt). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-28 01:41 Message: Logged In: YES user_id=11105 Jack, does this patch fix your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 From noreply@sourceforge.net Mon Jan 28 18:37:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 10:37:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Laurent Pointal (pointal) Date: 2002-01-28 10:37 Message: Logged In: YES user_id=440351 Ok, loewis patch msvc.diff works well, I does the setup.py build of StandaloneZODB completly. Now I'm trying StandaloneZODB test.py script (seem to be a long running test). A+ Laurent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 22:31 Message: Logged In: YES user_id=21627 Since this is msvccompiler, it should be safe to encode Unicode strings using the mbcs encoding. Laurent, can you please try the attached patch and report whether it solves the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 14:02 Message: Logged In: YES user_id=21627 I think the right solution would be to apply the file system encoding to each of the strings (either to the Unicode strings, producing byte strings, or vice versa). That, of course, would require that the file system encoding is exposed to the application. I have a PEP in mind titled "Unicode at system interfaces", which would include exposing the file system encoding, but I wanted to wait to see reactions (hopefully acceptance) of PEP 277 first. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-27 10:17 Message: Logged In: YES user_id=31435 Laurent, the last component of your PATH: 'C:\Docs\Boulot\S\xe9minaireLORIA-jan2002\DemoCORBA' in not a Unicode string but contains a "funny character" (chr(0xe9)). It probably doesn't look funny to you , but the Unicode subsystem believes by default that non- Unicode strings are plain 7-bit ASCII, and \xe9 isn't legitimate under that belief. Because there are *some* Unicode strings in your PATH, the join attempt needs to convert all strings to Unicode, but it can't do it (the last path component isn't a valid encoding under the default belief). As a quick workaround, you could remove that entry from your PATH. Or you could set Python's belief about the default encoding to match your belief (it's impossible for Python to guess this, alas -- for all it knows your last path component was intended to be German or Navajo). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Mon Jan 28 20:16:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 12:16:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-509805 ] tempfile.gettempdir not threadsafe Message-ID: Bugs item #509805, was opened at 2002-01-28 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509805&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: tempfile.gettempdir not threadsafe Initial Comment: tempfile.gettempdir() tests whether a candidate temp dir is usable by creating a file in it and writing to it. If that succeeds, it unlinks the file and says "great". Alas, the logic appears to be flawed in different ways for different platforms. Examples: + Windows. The name of the temp file is just the pid with "test" tacked on to the end. *All* threads calling this see the same name. So threads A and B can both open the test file at the same time, thread A closes it and tries to unlink it, and blows up then because thread B still has the file open (you can't unlink an open file on Windows). I've seen this happen . + Non-Linux Unix flavors. Again all threads see the same file name. The test file is opened with os.O_RDWR | os.O_CREAT | os.O_EXCL so if thread A gets in first, I expect all other threads will suffer a bogus error until thread A finishes unlinking it. The consequece is that the other threads may be fooled into (erroneously) believing that there are no usable temp directories. + Linux. Someone else needs to think about this. I expect it's safe on Linux because different threads have different pids (so don't collide on the test file name) -- although I expect it remains vulnerable to junk files sitting around that just happen to have the same name. + 'mac' and 'riscos': no idea. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509805&group_id=5470 From noreply@sourceforge.net Mon Jan 28 20:54:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 12:54:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-28 10:37 Message: Logged In: YES user_id=440351 Ok, loewis patch msvc.diff works well, I does the setup.py build of StandaloneZODB completly. Now I'm trying StandaloneZODB test.py script (seem to be a long running test). A+ Laurent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 22:31 Message: Logged In: YES user_id=21627 Since this is msvccompiler, it should be safe to encode Unicode strings using the mbcs encoding. Laurent, can you please try the attached patch and report whether it solves the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 14:02 Message: Logged In: YES user_id=21627 I think the right solution would be to apply the file system encoding to each of the strings (either to the Unicode strings, producing byte strings, or vice versa). That, of course, would require that the file system encoding is exposed to the application. I have a PEP in mind titled "Unicode at system interfaces", which would include exposing the file system encoding, but I wanted to wait to see reactions (hopefully acceptance) of PEP 277 first. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-27 10:17 Message: Logged In: YES user_id=31435 Laurent, the last component of your PATH: 'C:\Docs\Boulot\S\xe9minaireLORIA-jan2002\DemoCORBA' in not a Unicode string but contains a "funny character" (chr(0xe9)). It probably doesn't look funny to you , but the Unicode subsystem believes by default that non- Unicode strings are plain 7-bit ASCII, and \xe9 isn't legitimate under that belief. Because there are *some* Unicode strings in your PATH, the join attempt needs to convert all strings to Unicode, but it can't do it (the last path component isn't a valid encoding under the default belief). As a quick workaround, you could remove that entry from your PATH. Or you could set Python's belief about the default encoding to match your belief (it's impossible for Python to guess this, alas -- for all it knows your last path component was intended to be German or Navajo). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Mon Jan 28 23:13:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 15:13:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-509805 ] tempfile.gettempdir not threadsafe Message-ID: Bugs item #509805, was opened at 2002-01-28 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509805&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Tim Peters (tim_one) Summary: tempfile.gettempdir not threadsafe Initial Comment: tempfile.gettempdir() tests whether a candidate temp dir is usable by creating a file in it and writing to it. If that succeeds, it unlinks the file and says "great". Alas, the logic appears to be flawed in different ways for different platforms. Examples: + Windows. The name of the temp file is just the pid with "test" tacked on to the end. *All* threads calling this see the same name. So threads A and B can both open the test file at the same time, thread A closes it and tries to unlink it, and blows up then because thread B still has the file open (you can't unlink an open file on Windows). I've seen this happen . + Non-Linux Unix flavors. Again all threads see the same file name. The test file is opened with os.O_RDWR | os.O_CREAT | os.O_EXCL so if thread A gets in first, I expect all other threads will suffer a bogus error until thread A finishes unlinking it. The consequece is that the other threads may be fooled into (erroneously) believing that there are no usable temp directories. + Linux. Someone else needs to think about this. I expect it's safe on Linux because different threads have different pids (so don't collide on the test file name) -- although I expect it remains vulnerable to junk files sitting around that just happen to have the same name. + 'mac' and 'riscos': no idea. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-28 15:13 Message: Logged In: YES user_id=31435 Fixed in a cheap but robust x-platform way, in Lib/tempfile.py; new revision: 1.35 Everyone can stop wondering about Linux, mac, and riscos now . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509805&group_id=5470 From noreply@sourceforge.net Tue Jan 29 10:24:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 02:24:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-509117 ] encoding error when joining path Message-ID: Bugs item #509117, was opened at 2002-01-27 03:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 Category: Distutils Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: Laurent Pointal (pointal) Assigned to: Nobody/Anonymous (nobody) Summary: encoding error when joining path Initial Comment: [platform] Problem on Python 2.1.1 and Python 2.2. Platform Windows 2000 SP2, french version. With MSVC++6 SP4. [seealso] It looks like to be a non-us platform problem, see: http://mail.python.org/pipermail/python-list/2002- January/083903.html [description] While installing StandaloneZODB, python setup.py build ended with the followiong traceback: ...[zipped many file copying & Co]... copying zdaemon\ZDaemonLogging.py -> build\lib.win32- 2.1\zdaemon copying zdaemon\__init__.py -> build\lib.win32- 2.1\zdaemon running build_ext Traceback (most recent call last): File "setup.py", line 108, in ? headers = ['ExtensionClass/src/ExtensionClass.h', 'ZODB/cPersistence.h'], File "t:\dev\python21\lib\distutils\core.py", line 138, in setup dist.run_commands() File "t:\dev\python21\lib\distutils\dist.py", line 899, in run_commands self.run_command(cmd) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build.py", line 106, in run self.run_command(cmd_name) File "t:\dev\python21\lib\distutils\cmd.py", line 328, in run_command self.distribution.run_command(command) File "t:\dev\python21\lib\distutils\dist.py", line 919, in run_command cmd_obj.run() File "t:\dev\python21\lib\distutils\command\build_ext.py", line 230, in run force=self.force) File "t:\dev\python21\lib\distutils\ccompiler.py", line 957, in new_compiler return klass (verbose, dry_run, force) File "t:\dev\python21\lib\distutils\msvccompiler.py", line 220, in __init__ os.environ['path'] = string.join(path,';') File "t:\dev\python21\lib\string.py", line 128, in join return sep.join(words) UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-29 02:24 Message: Logged In: YES user_id=21627 Committed as msvccompiler.py 1.44. ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-28 10:37 Message: Logged In: YES user_id=440351 Ok, loewis patch msvc.diff works well, I does the setup.py build of StandaloneZODB completly. Now I'm trying StandaloneZODB test.py script (seem to be a long running test). A+ Laurent. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 22:31 Message: Logged In: YES user_id=21627 Since this is msvccompiler, it should be safe to encode Unicode strings using the mbcs encoding. Laurent, can you please try the attached patch and report whether it solves the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 14:02 Message: Logged In: YES user_id=21627 I think the right solution would be to apply the file system encoding to each of the strings (either to the Unicode strings, producing byte strings, or vice versa). That, of course, would require that the file system encoding is exposed to the application. I have a PEP in mind titled "Unicode at system interfaces", which would include exposing the file system encoding, but I wanted to wait to see reactions (hopefully acceptance) of PEP 277 first. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-27 10:17 Message: Logged In: YES user_id=31435 Laurent, the last component of your PATH: 'C:\Docs\Boulot\S\xe9minaireLORIA-jan2002\DemoCORBA' in not a Unicode string but contains a "funny character" (chr(0xe9)). It probably doesn't look funny to you , but the Unicode subsystem believes by default that non- Unicode strings are plain 7-bit ASCII, and \xe9 isn't legitimate under that belief. Because there are *some* Unicode strings in your PATH, the join attempt needs to convert all strings to Unicode, but it can't do it (the last path component isn't a valid encoding under the default belief). As a quick workaround, you could remove that entry from your PATH. Or you could set Python's belief about the default encoding to match your belief (it's impossible for Python to guess this, alas -- for all it knows your last path component was intended to be German or Navajo). ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-27 08:32 Message: Logged In: YES user_id=12800 Max M's problem (referred to w/ the above url) appeared to be related to non-ASCII characters in his path. His resolution is here: http://mail.python.org/pipermail/python-list/2002-January/083957.html ---------------------------------------------------------------------- Comment By: Laurent Pointal (pointal) Date: 2002-01-27 04:07 Message: Logged In: YES user_id=440351 Here is the "print repr(path)" result: [u'T:\dev\MSVS\Common\MSDev98\Bin', u'T:\dev\MSVS\VC98\BIN', u'T:\dev\MSVS\Common\TOOLS', u'T:\dev\MSVS\Common\ TOOLS\WINNT', u'C:\WINNT\system32', u'C:\WINNT', u'C:\WINNT\System32\Wbem', u't:\dev\python21', u'T:\dev\omni\bin\x 86_win32', 'C:\WINNT\system32', 'C:\WINNT', 'C:\WINNT\S ystem32 \Wbem', 't:\dev\python21', 'T:\dev\MSVS\Common\Tools\ \ WinNT', 'T:\dev\MSVS\Common\MSDev98 \Bin', 'T:\dev\MSVS\Common\Tools', 'T:\dev\MSVS\VC98 \bin', 't:\Tools\TeX\bin\ \win32', 'T:\dev\omni\bin\x86_win32', 'T:\dev\root\bi n', 'T:\dev\root\usr\X11R6 \bin', 't:\dev\bins', 'T:\dev\jdk 1.3.1_01\bin', 'T:\dev\jdk1.3.1_01 \jre\bin', 'T:\dev\python21 \PyQt\bin', 't:\dev\python21\Scripts', 'C:\Program Fil es\WinRAR', 'C:\Program Files\ARJ', 'T:\Tools\WaveMetrics\Igor Pro Folder', 't:\Tools\qt\bin', 'C:\Docs\Boulot\S\xe9 minaireLORIA-jan2002\DemoCORBA'] ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-27 03:30 Message: Logged In: YES user_id=21627 Can you please enhance your local copy of distutils/msvccompiler to add a line of print repr(path) immediately above line 220, and report the output? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509117&group_id=5470 From noreply@sourceforge.net Tue Jan 29 14:38:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 06:38:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-509215 ] formatting error api/iterator.html Message-ID: Bugs item #509215, was opened at 2002-01-27 09:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509215&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: formatting error api/iterator.html Initial Comment: http://www.python.org/doc/current/api/iterator.html also erroneously includes the docs on the buffer protocol, which have apparently remained in LaTeX markup rather than getting translated to HTML. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-29 06:38 Message: Logged In: YES user_id=3066 Fixed in CVS for both Python 2.2.1 and 2.3. There will be a maintenance release of the 2.2 docs which will include this correction. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509215&group_id=5470 From noreply@sourceforge.net Tue Jan 29 14:58:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 06:58:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-509281 ] cheeseshop example shows wrong output Message-ID: Bugs item #509281, was opened at 2002-01-27 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509281&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ed James-Beckham (edj) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: cheeseshop example shows wrong output Initial Comment: The cheeseshop example in 4.7.2 shows the output to be: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese shopkeeper : Michael Palin sketch : Cheese Shop Sketch when in fact, from the IDLE, one gets: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- shopkeeper : Michael Palin sketch : Cheese Shop Sketch client : John Cleese Experimenting, it seems that the first keyword argument ('client') always appears _last_ in the output. If this is, in fact, a bug in Python, please change the category appropriately and pass it on. Thanks, -edj ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-29 06:58 Message: Logged In: YES user_id=3066 Fixed in Doc/tut/tut.tex revisions 1.158 and 1.156.4.1.2.1 (???). Sorted the list of keys before output, and added a note about what we get if we skip the sort. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-27 12:36 Message: Logged In: YES user_id=31435 The order of entires in dict.keys() is not defined, and can change even across program runs. The docs could explain that, or sort dict.keys() before printing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509281&group_id=5470 From noreply@sourceforge.net Tue Jan 29 15:25:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 07:25:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-510186 ] clean doesn't Message-ID: Bugs item #510186, was opened at 2002-01-29 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: clean doesn't Initial Comment: rRnning "python setup.py clean" says: % python setup.py clean running clean removing 'build/temp.linux-i686-2.2' (and everything under it) However, following that with an immediate "python setup.py build" reports: % python setup.py build running build running build_py not copying RSWM/__init__.py (output up-to-date) running build_ext skipping 'rswm' extension (up-to-date) Shouldn't the "clean" command simply delete the build directory? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470 From noreply@sourceforge.net Tue Jan 29 15:31:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 07:31:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-510186 ] clean doesn't Message-ID: Bugs item #510186, was opened at 2002-01-29 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: clean doesn't Initial Comment: rRnning "python setup.py clean" says: % python setup.py clean running clean removing 'build/temp.linux-i686-2.2' (and everything under it) However, following that with an immediate "python setup.py build" reports: % python setup.py build running build running build_py not copying RSWM/__init__.py (output up-to-date) running build_ext skipping 'rswm' extension (up-to-date) Shouldn't the "clean" command simply delete the build directory? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-29 07:31 Message: Logged In: YES user_id=6656 Hmm. Does "python setup.py clean --all" do what you want/expect? Agree this should possibly be the default, by analogy with "make clean". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470 From noreply@sourceforge.net Tue Jan 29 16:28:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 08:28:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-510218 ] strftime() gets timezone wrong Message-ID: Bugs item #510218, was opened at 2002-01-29 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510218&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Nobody/Anonymous (nobody) Summary: strftime() gets timezone wrong Initial Comment: Platform: Debian Linux (sid/unstable) glibc 2.2.4 Python 2.2 Python's time.strftime() gets the timezone wrong in various creative ways. The timezone variable is set correctly: >>> time.timezone 18000 (That's 5 hours behind UTC, which is correct.) However, the %z and %Z format codes are inconsistent, and one or the other is always wrong: >>> time.strftime("%H:%M %z (%Z)", time.localtime(time.time())) '11:25 +0000 (EST)' >>> time.strftime("%H:%M %z (%Z)", time.gmtime(time.time())) '16:25 +0000 (EST)' %z seems to ignore the fact that I'm not in UTC; %Z is the opposite. Note that the "date" command (from GNU shellutils 2.0.11) gets it right in both cases: $ date +"%H:%M:%S %z (%Z)" 11:27:18 -0500 (EST) $ date --utc +"%H:%M:%S %z (%Z)" 16:27:20 +0000 (UTC) The obvious next step is to write a little C program to see if libc or Python is broken -- ie. is the "date" command doing special magic here? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510218&group_id=5470 From noreply@sourceforge.net Tue Jan 29 17:44:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 09:44:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-510218 ] strftime() gets timezone wrong Message-ID: Bugs item #510218, was opened at 2002-01-29 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510218&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Nobody/Anonymous (nobody) Summary: strftime() gets timezone wrong Initial Comment: Platform: Debian Linux (sid/unstable) glibc 2.2.4 Python 2.2 Python's time.strftime() gets the timezone wrong in various creative ways. The timezone variable is set correctly: >>> time.timezone 18000 (That's 5 hours behind UTC, which is correct.) However, the %z and %Z format codes are inconsistent, and one or the other is always wrong: >>> time.strftime("%H:%M %z (%Z)", time.localtime(time.time())) '11:25 +0000 (EST)' >>> time.strftime("%H:%M %z (%Z)", time.gmtime(time.time())) '16:25 +0000 (EST)' %z seems to ignore the fact that I'm not in UTC; %Z is the opposite. Note that the "date" command (from GNU shellutils 2.0.11) gets it right in both cases: $ date +"%H:%M:%S %z (%Z)" 11:27:18 -0500 (EST) $ date --utc +"%H:%M:%S %z (%Z)" 16:27:20 +0000 (UTC) The obvious next step is to write a little C program to see if libc or Python is broken -- ie. is the "date" command doing special magic here? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-29 09:44 Message: Logged In: YES user_id=38388 The time integer you pass into strftime() doesn't carry along any timezone information, so strftime() has to make some assumption as to what it is dealing with. The default assumption naturally is local time and that's what strftime() uses. Time zones simply don't work with non-local times. I'd suggest to close this as 'not a bug'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510218&group_id=5470 From noreply@sourceforge.net Tue Jan 29 19:34:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 11:34:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-493837 ] Distutils not finding Python on Win2K Message-ID: Bugs item #493837, was opened at 2001-12-16 00:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 Category: Distutils Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: Distutils not finding Python on Win2K Initial Comment: Thomas (or anyone else), can you help this fellow who posted to the Tutor list? If there's a systematic problem here with 2.2c1, we've only got a window of a few days to fix it. """ From: tutor-admin@python.org [mailto:tutor- admin@python.org]On Behalf Of Quniceleaf Listservs Sent: Sunday, December 16, 2001 2:02 AM To: tutor@python.org Subject: [Tutor] Python not being found in the registry? I'm using Python 2.2c1 on a Win2K machine. I've repeatedly tried installing two Python addons from different sources (XIST and the MySQL-interface) that each use a Windows installer program based on distutils-1.0.2pre. Both need to locate the Python installation before proceeding with the setup, and will not allow the user to browse and specify the location themselves. Unfortunately, neither can ever find a Python installation, and thus will not install. I've tried this repeatedly with Python 2.1, 2.2b, 2.2c1, and with ActiveState's distribution. In each case the installation is reflected in the Windows registry, but only the ActiveState install appears in the setup (and due to instability issues I am sticking with the standard distribution). Has anyone else encountered this problem? - Brian """ Unfortunately, the Tutor list reports his email address as listservb@quinceleaf.com, which doesn't seem reasonable. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-29 11:34 Message: Logged In: YES user_id=11105 This should have been closed some time ago. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-17 09:37 Message: Logged In: YES user_id=31435 Thanks, guys -- I think you've explained it. Feel free to close this if you can't think of anything else to do -- I don't have a way to contact the OP. PythonLabs installers previous to 2.2 used a much older version of Wise (dating back to when Win95 was brand new), and there are many problems with Win2K installs, esp. under non-Admin accounts; I've seen the bogus "corrupt installation" msg myself. Nothing we can do about it, alas. The 2.2 installer uses an up-to-date Wise, and the install script was extensively reworked to support non-Admin installs on Win2K; and you can use the "advanced options" screen in the 2.2 installer to select a non-Admin install even if you are an Admin (then it writes under HKCU instead of HKLM, and stores DLLs in the Python root instead of in the system dir). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-12-17 02:44 Message: Logged In: YES user_id=11105 I think MAL is right: It seems Brian is trying to install XIST and MySQL, which are built for Python2.1 (only), and the installer does not show (for purpose) the 2.2 installation. Probably the installer should display a clear message to the user if there are other Python versions not matching the requirements for the package to install. (But maybe also the packagers of packages should clearly indicate that this is build for a certain Python version?) The only other possibility could be that the bdist_wininst installer does not work correctly if the registry entries are under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE. The code is there - but how can I test it. Tried to install python2.1.1 when using the Guest account (Win2k, SP2), but all I get is 'corrupt installation detected'. Is this a known problem? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-12-17 01:28 Message: Logged In: YES user_id=38388 One problem could be that Brian is trying to install a binary for a non-installed Python version on the machine. In that case, the installer does not display any entries in the Python directory selection box. Another possibility is fixing the binaries to use the latest distutils version available. Thomas Heller made some changes which solved a few problems in distutils 1.0.3 AFAIR. As a test I'd suggest to install egenix-mx-base on the machine and see what you get (the installer for that package was built using distutils 2.0.3). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493837&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:00:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:00:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-510373 ] Make generator factory a type name Message-ID: Bugs item #510373, was opened at 2002-01-29 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510373&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Make generator factory a type name Initial Comment: Make the generator factory function, iter() a type name so that iter==types.GeneratorType. This extends to interators the convenience given to other factor functions: int, long, float, complex, str, unicode, tuple, list, dict, and object. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510373&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:13:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:13:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-510384 ] Separate Scope for List Comprehensions Message-ID: Bugs item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:16:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:16:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-510373 ] Make generator factory a type name Message-ID: Bugs item #510373, was opened at 2002-01-29 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510373&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Make generator factory a type name Initial Comment: Make the generator factory function, iter() a type name so that iter==types.GeneratorType. This extends to interators the convenience given to other factor functions: int, long, float, complex, str, unicode, tuple, list, dict, and object. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-29 14:16 Message: Logged In: NO I can't log in (on the road) but this is Guido. iter() can't be a standard type because it doesn't return an object of a specific type. Iterators are described by a convention (must support next() and __iter__()), not by a type. Somebody reject this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510373&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:19:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:19:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-510388 ] Enhance xrange() Message-ID: Bugs item #510388, was opened at 2002-01-29 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance xrange() Initial Comment: Make the STOP argument optional so that xrange can produce an infinite series. for i in xrange(): if test(i): break print i, 'Failed test. Continuing search.' Also, add two methods to xrange, .__iter__ and .next() so that xrange can be used interchangably with other generators. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:26:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:26:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-510373 ] Make generator factory a type name Message-ID: Bugs item #510373, was opened at 2002-01-29 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510373&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Make generator factory a type name Initial Comment: Make the generator factory function, iter() a type name so that iter==types.GeneratorType. This extends to interators the convenience given to other factor functions: int, long, float, complex, str, unicode, tuple, list, dict, and object. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-01-29 14:26 Message: Logged In: YES user_id=35752 iterators != generators. Rejected. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-29 14:16 Message: Logged In: NO I can't log in (on the road) but this is Guido. iter() can't be a standard type because it doesn't return an object of a specific type. Iterators are described by a convention (must support next() and __iter__()), not by a type. Somebody reject this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510373&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:31:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:31:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-510394 ] Add base classes for numeric types Message-ID: Bugs item #510394, was opened at 2002-01-29 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510394&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add base classes for numeric types Initial Comment: Create a class hierarchy for numeric types (similar to the structure for exceptions) so that the following work: issubclass(int,numeric)==1 issubclass(int,real)==1 issubclass(complex,real)==0 isinstance( 3.14, real ) == 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510394&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:43:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:43:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-508700 ] import of C-extension causes crash Message-ID: Bugs item #508700, was opened at 2002-01-25 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 Category: Threads Group: None >Status: Deleted >Resolution: Rejected Priority: 5 Submitted By: Keith Farmer (deoradh) Assigned to: Nobody/Anonymous (nobody) Summary: import of C-extension causes crash Initial Comment: PythonWin 2.1 (#15, Apr 16 2001, 18:25:49) Running on Win2k SP2 (both Pro and Server) Source code for the extension is at http://www.thuban.org/projects (see AstroMath). (Zip file uploaded) As suggested, I set up a couple threading/non- threading tests outside of Zope. Here are the results, and the sourcecode for the scripts. My guess now is that it's a Python error, or something that I don't know about how C-extensions behave under Python threads. AstroMathTest.py -- threaded, import outside of the thread run() method AstroMathTest-2.py -- threaded, import inside the thread run() method AstroMathTest-3.py -- unthreaded, import outside of the class AstroMathTest.py triggers an abnormal termination (when running under Zope, this crashes the server). The others execute normally. ---------- Keith J. Farmer kfarmer@thuban.org http://www.thuban.org D:\Users\kfarmer\Desktop>AstroMathTest.py abnormal program termination D:\Users\kfarmer\Desktop>AstroMathTest-2.py Period: 2448976 - 2448982 Body: 2 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449067 Body: 9 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449010 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed D:\Users\kfarmer\Desktop>AstroMathTest-3.py Period: 2448976 - 2449003 Body: 2 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2448982 Body: 6 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2449075 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 From noreply@sourceforge.net Tue Jan 29 22:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 14:45:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-508700 ] import of C-extension causes crash Message-ID: Bugs item #508700, was opened at 2002-01-25 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 Category: Threads Group: None Status: Deleted Resolution: Rejected Priority: 5 Submitted By: Keith Farmer (deoradh) Assigned to: Nobody/Anonymous (nobody) Summary: import of C-extension causes crash Initial Comment: PythonWin 2.1 (#15, Apr 16 2001, 18:25:49) Running on Win2k SP2 (both Pro and Server) Source code for the extension is at http://www.thuban.org/projects (see AstroMath). (Zip file uploaded) As suggested, I set up a couple threading/non- threading tests outside of Zope. Here are the results, and the sourcecode for the scripts. My guess now is that it's a Python error, or something that I don't know about how C-extensions behave under Python threads. AstroMathTest.py -- threaded, import outside of the thread run() method AstroMathTest-2.py -- threaded, import inside the thread run() method AstroMathTest-3.py -- unthreaded, import outside of the class AstroMathTest.py triggers an abnormal termination (when running under Zope, this crashes the server). The others execute normally. ---------- Keith J. Farmer kfarmer@thuban.org http://www.thuban.org D:\Users\kfarmer\Desktop>AstroMathTest.py abnormal program termination D:\Users\kfarmer\Desktop>AstroMathTest-2.py Period: 2448976 - 2448982 Body: 2 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449067 Body: 9 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449010 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed D:\Users\kfarmer\Desktop>AstroMathTest-3.py Period: 2448976 - 2449003 Body: 2 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2448982 Body: 6 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2449075 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed ---------------------------------------------------------------------- >Comment By: Keith Farmer (deoradh) Date: 2002-01-29 14:45 Message: Logged In: YES user_id=410277 CoInitialize/CoUnintialize needed to be included in the ADO calls. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 From noreply@sourceforge.net Tue Jan 29 23:44:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 15:44:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-508700 ] import of C-extension causes crash Message-ID: Bugs item #508700, was opened at 2002-01-25 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 Category: Threads >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Keith Farmer (deoradh) Assigned to: Nobody/Anonymous (nobody) Summary: import of C-extension causes crash Initial Comment: PythonWin 2.1 (#15, Apr 16 2001, 18:25:49) Running on Win2k SP2 (both Pro and Server) Source code for the extension is at http://www.thuban.org/projects (see AstroMath). (Zip file uploaded) As suggested, I set up a couple threading/non- threading tests outside of Zope. Here are the results, and the sourcecode for the scripts. My guess now is that it's a Python error, or something that I don't know about how C-extensions behave under Python threads. AstroMathTest.py -- threaded, import outside of the thread run() method AstroMathTest-2.py -- threaded, import inside the thread run() method AstroMathTest-3.py -- unthreaded, import outside of the class AstroMathTest.py triggers an abnormal termination (when running under Zope, this crashes the server). The others execute normally. ---------- Keith J. Farmer kfarmer@thuban.org http://www.thuban.org D:\Users\kfarmer\Desktop>AstroMathTest.py abnormal program termination D:\Users\kfarmer\Desktop>AstroMathTest-2.py Period: 2448976 - 2448982 Body: 2 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449067 Body: 9 N: 1000 Results: [correct results -- KF] Period: 2448976 - 2449010 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed D:\Users\kfarmer\Desktop>AstroMathTest-3.py Period: 2448976 - 2449003 Body: 2 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2448982 Body: 6 N: 1000 Results: [correct results -- KF]Period: 2448976 - 2449075 Body: 2 N: 1000 Results: [correct results -- KF]All threads completed ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-29 15:44 Message: Logged In: YES user_id=31435 I'm glad you're unstuck! Let me suggest another problem: instances of return AstroMathError; are going to burn you sooner or later, because that's a Python object and you're not incrementing its refcount before the return. It's unclear whether you want that to be a "special value" return, or to raise an exception. If you just want to return it as a special value, Py_INCREF it before the return. If you want it to raise an exception, pass it to PyErr_SetObject() first and then return NULL. ---------------------------------------------------------------------- Comment By: Keith Farmer (deoradh) Date: 2002-01-29 14:45 Message: Logged In: YES user_id=410277 CoInitialize/CoUnintialize needed to be included in the ADO calls. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508700&group_id=5470 From noreply@sourceforge.net Wed Jan 30 00:51:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 16:51:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-217195 ] Broken \ref link in documentation Message-ID: Bugs item #217195, was opened at 2000-10-18 11:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Broken \ref link in documentation Initial Comment: [Report received by python-docs.] From: Roy Smith Date: Wed, 18 Oct 2000 14:45:25 -0700 On the page http://www.python.org/doc/current/ref/exceptions.html, if I click on the link for secion 7.4 (http://www.python.org/doc/current/ref/node83.html#try), I get an Error 404: file not found. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-29 16:51 Message: Logged In: NO ergdfvgdfdfgsdgff ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-12-12 13:54 Message: I'll note that I think this is a LaTeX2HTML bug, but I need to spend some time digging into the \ref{} handling. It seems to have other problems as well. ;-( ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470 From noreply@sourceforge.net Wed Jan 30 10:51:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 02:51:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-510644 ] test_curses segfaults Message-ID: Bugs item #510644, was opened at 2002-01-30 02:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510644&group_id=5470 Category: Extension Modules Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: test_curses segfaults Initial Comment: [alerted by post on c.l.py] test_curses segfault trying to free something it shouldn't. Perhaps we haven't been running this as often as we should? At all? Currently trying to find the problem by binary chop on revisions of cursesmodule... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510644&group_id=5470 From noreply@sourceforge.net Wed Jan 30 15:44:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 07:44:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-510644 ] test_curses segfaults Message-ID: Bugs item #510644, was opened at 2002-01-30 02:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510644&group_id=5470 Category: Extension Modules Group: Python 2.2.1 candidate >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: test_curses segfaults Initial Comment: [alerted by post on c.l.py] test_curses segfault trying to free something it shouldn't. Perhaps we haven't been running this as often as we should? At all? Currently trying to find the problem by binary chop on revisions of cursesmodule... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-01-30 07:44 Message: Logged In: YES user_id=6656 I think I've fixed this in revision 2.65 of _cursesmodule.c. It was a PyObject_New/PyMem_Del mismatch, which caused problems --with-pymalloc. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510644&group_id=5470 From noreply@sourceforge.net Wed Jan 30 15:50:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 07:50:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-510388 ] Enhance xrange() Message-ID: Bugs item #510388, was opened at 2002-01-29 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance xrange() Initial Comment: Make the STOP argument optional so that xrange can produce an infinite series. for i in xrange(): if test(i): break print i, 'Failed test. Continuing search.' Also, add two methods to xrange, .__iter__ and .next() so that xrange can be used interchangably with other generators. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:50 Message: Logged In: NO This is Guido (can't log in right now). I'll reject this request; fancy xrange() features are being deprecated. You can get the same effect with xrange (sys.maxint). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 From noreply@sourceforge.net Wed Jan 30 15:52:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 07:52:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-510384 ] Separate Scope for List Comprehensions Message-ID: Bugs item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:52 Message: Logged In: NO This is Guido; I can't log in here on the road. I believe this has been fixed in Python 2.2, and possibly in 2.1.2. Can you check that? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 From noreply@sourceforge.net Wed Jan 30 16:17:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 08:17:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-30 08:17 Message: Logged In: YES user_id=3066 Fixed in Lib/string.py revisions 1.61, 1.60.16.1, and 1.59.4.1. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-21 00:38 Message: Logged In: YES user_id=196786 By the way, the reason I ended up looking at the library docs (and docstring) for the string module was that I did a simple text search on index.html from the library reference (I'm new to Python). The first match is UserString, and the second is 4. String Services, under which can be found section 4.1 "string -- Common string operations". "string" is in a monospaced font, and looks as much like a type as a module name, so I assumed that it applied to the built-in string type. I later found the documentation for the string type in section 2.2.6.1 "String Methods". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 20:45 Message: Logged In: YES user_id=31435 Guido's right, I did print "".split.__doc__ without even considering that someone may still be doing the archaic print string.split.__doc__ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 20:30 Message: Logged In: NO Tim was looking at the doc string for the split *method* of string objects, which is correct. But the complaint was about the split *function* in the (no longer needed, but still supported) string *module*, which is indeed wrong -- still in 2.2. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-20 20:20 Message: Logged In: YES user_id=196786 Thanks for responding. The docstring was from Python 2.1.2 (Debian 2.1.2-2): Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) In 2.2, it seems to be corrected: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) The library documentation for 2.2 still says that maxsplit defaults to 0, though apparently it defaults to -1, so that needs to be fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Wed Jan 30 16:20:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 08:20:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-510384 ] Separate Scope for List Comprehensions Message-ID: Bugs item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-01-30 08:20 Message: Logged In: YES user_id=80475 I verified that this has NOT been fixed in Python 2.2: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> i=10 >>> temp = [str(i) for i in range(5)] >>> print i 4 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:52 Message: Logged In: NO This is Guido; I can't log in here on the road. I believe this has been fixed in Python 2.2, and possibly in 2.1.2. Can you check that? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 From noreply@sourceforge.net Wed Jan 30 17:04:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 09:04:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-510388 ] Enhance xrange() Message-ID: Bugs item #510388, was opened at 2002-01-29 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open >Resolution: Rejected Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance xrange() Initial Comment: Make the STOP argument optional so that xrange can produce an infinite series. for i in xrange(): if test(i): break print i, 'Failed test. Continuing search.' Also, add two methods to xrange, .__iter__ and .next() so that xrange can be used interchangably with other generators. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:50 Message: Logged In: NO This is Guido (can't log in right now). I'll reject this request; fancy xrange() features are being deprecated. You can get the same effect with xrange (sys.maxint). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 From noreply@sourceforge.net Wed Jan 30 17:05:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 09:05:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-510388 ] Enhance xrange() Message-ID: Bugs item #510388, was opened at 2002-01-29 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance xrange() Initial Comment: Make the STOP argument optional so that xrange can produce an infinite series. for i in xrange(): if test(i): break print i, 'Failed test. Continuing search.' Also, add two methods to xrange, .__iter__ and .next() so that xrange can be used interchangably with other generators. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:50 Message: Logged In: NO This is Guido (can't log in right now). I'll reject this request; fancy xrange() features are being deprecated. You can get the same effect with xrange (sys.maxint). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510388&group_id=5470 From noreply@sourceforge.net Wed Jan 30 19:33:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 11:33:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-510384 ] Separate Scope for List Comprehensions Message-ID: Bugs item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:33 Message: Logged In: NO Oops, I misread your complaint. The bug that was fixed was that sometimes the variables end up in the *global* scope. This was discussed when it was designed and it was decided to do it this way. It's similar to what a regular for loop does: for i in range(10): pass print i prints 10. I'll reject this when I can log in to SF again. --Guido (again) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-01-30 08:20 Message: Logged In: YES user_id=80475 I verified that this has NOT been fixed in Python 2.2: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> i=10 >>> temp = [str(i) for i in range(5)] >>> print i 4 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:52 Message: Logged In: NO This is Guido; I can't log in here on the road. I believe this has been fixed in Python 2.2, and possibly in 2.1.2. Can you check that? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 From noreply@sourceforge.net Wed Jan 30 19:33:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 11:33:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-510868 ] Solaris 2.7 make chokes. Message-ID: Bugs item #510868, was opened at 2002-01-30 11:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sharad Satsangi (sharadinfozen) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 2.7 make chokes. Initial Comment: I'm building python2.2 on a Solaris2.7 box, an Ultra- 10. I get a segmentation fault error at 'xreadlines' when I try the make. I am not sure why. Logs of the configuration script & make are attached. (in one concatenated file, I could not tell how to upload more than one file). Any help will be greatly appreciated. thanks! -sharad. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470 From noreply@sourceforge.net Wed Jan 30 19:34:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 11:34:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-510384 ] Separate Scope for List Comprehensions Message-ID: Bugs item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:34 Message: Logged In: NO Sorry, the bug that was fixed was about global scope. This was discussed when list comprehensions were designed, and it was a conscious decision that won't be changed. It's the same as for regular for loops. --Guido (still can't log in) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:33 Message: Logged In: NO Oops, I misread your complaint. The bug that was fixed was that sometimes the variables end up in the *global* scope. This was discussed when it was designed and it was decided to do it this way. It's similar to what a regular for loop does: for i in range(10): pass print i prints 10. I'll reject this when I can log in to SF again. --Guido (again) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-01-30 08:20 Message: Logged In: YES user_id=80475 I verified that this has NOT been fixed in Python 2.2: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> i=10 >>> temp = [str(i) for i in range(5)] >>> print i 4 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:52 Message: Logged In: NO This is Guido; I can't log in here on the road. I believe this has been fixed in Python 2.2, and possibly in 2.1.2. Can you check that? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510384&group_id=5470 From noreply@sourceforge.net Wed Jan 30 20:14:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 12:14:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-499788 ] Assertion failed (eval_code2) Message-ID: Bugs item #499788, was opened at 2002-01-05 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Jeremy Hylton (jhylton) Summary: Assertion failed (eval_code2) Initial Comment: [original report can be found at http://bugs.debian.org/127167] The version mentioned is the 2.1 maintainance branch, dated 2000-12-20; I did not get reports for 2.1.1, 2.2 is reported to work ok. /usr/lib/zope/lib/python/Products/Squishdot# python2.1: ../Python/ceval.c:687: eval_code2: Assertion ` (stack_pointer - f->f_valuestack) <= f->f_stacksize' failed. Another user got this error, while adding the Zope Tutorial product. The zope version at this time was 2.4.2. I cannot reproduce these reports myself. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 12:14 Message: Logged In: NO Well, I got it as well. Has it something to do with PPC? Please find server info below. Kristjan it-meedia@spunk:~ > cat /etc/SuSE-release SuSE Linux 7.1 (PPC) VERSION = 7.1 it-meedia@spunk:~ > uname -a Linux spunk 2.4.2 #1 Mon Mar 12 12:20:25 GMT 2001 ppc unknown it-meedia@spunk:~ > cat /proc/version Linux version 2.4.2 (root@CHRP-PReP.suse.de) (gcc version 2.95.2 19991024 (release)) #1 Mon Mar 12 12:20:25 GMT 2001 it-meedia@spunk:~ > cat /proc/cpuinfo processor : 0 cpu : 604r clock : 375MHz revision : 1.2 bogomips : 374.05 zero pages : total: 0 (0Kb) current: 0 (0Kb) hits: 0/0 (0%) machine : CHRP IBM,7046-B50 Zope info Zope Version (Zope 2.4.3 (source release, python 2.1, linux2), python 2.1.2, linux2) Python Version 2.1.2 (#1, Jan 28 2002, 23:34:39) [GCC 2.95.2 19991024 (release)] System Platform linux2 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-11 16:57 Message: Logged In: YES user_id=29957 In that case, I'm closing it as "Works for me". ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-11 08:41 Message: Logged In: YES user_id=60903 I couldn't reproduce the original error in squishdot-1.3 with CVS 20020107 and zope-2.5beta3. Neither with the import of the zope tutorial. The person who did get this error (L. Vogtmann) couldn't reproduce this error as well with the updated python version. I got no response from the original bug submitter. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:28 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:27 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-10 06:26 Message: Logged In: YES user_id=60903 I'll give it a try this weekend. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-10 06:01 Message: Logged In: YES user_id=29957 It really does look like it's the compiler stacksize thing - I'd like to either close or defer this, as 2.1.2 is ready to go. With a 'cannot reproduce...' I can't see what else can be done. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-05 07:24 Message: Logged In: YES user_id=6380 Jeremy, does this ring a bell? Was this before you fixed all bugs in the compiler package? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470 From noreply@sourceforge.net Wed Jan 30 20:53:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 12:53:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-505997 ] string.split docs are inconsistent Message-ID: Bugs item #505997, was opened at 2002-01-20 01:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 Category: Documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matt Zimmerman (mzimmerman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: string.split docs are inconsistent Initial Comment: string.split.__doc__ says: split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) This implies that len(split(s, sep, maxsplit)) <= maxsplit. In reality, however, it is <= maxsplit+1. This seems to be explained by the library documentation: split(s[, sep[, maxsplit]]) Return a list of the words of the string s. If the optional second argument sep is absent or None, the words are separated by arbitrary strings of whitespace characters (space, tab, newline, return, formfeed). If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements). Which indicates that maxsplit is in units of "splits" rather than "words", where words = splits + 1. Personally, i find the "number of splits" behaviour very counter-intuitive, and would much prefer "number of words". At any rate, the inconsistency needs to be corrected. Also, the sentence "The optional third argument maxsplit defaults to 0" implies that specifying maxsplit=0 is the same as not specifying it at all. This is not the case, however: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print "1x2x3".split('x') ['1', '2', '3'] >>> print "1x2x3".split('x',0) ['1x2x3'] Instead, it seems to cause sep to be disregarded, making split(anything,0) equivalent to split(). I don't have the python2.1 documentation installed at the moment, so I can't check the library reference for that version, but at least the string.split.__doc__ there is inconsistent with behaviour. This was originally submitted as Debian bug #129272 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-30 12:53 Message: Logged In: YES user_id=31435 People are thinking about this function the wrong way . In normal use with a maxsplit N, you want to get back at most N "words" *plus* "the leftover junk" (if any). The confusion comes from mistaking "words" for "total number of blobs returned". For example, if I want to get the hours and minutes out of a string of the form HH:MM:SS then splitting on ":" with maxsplit 2 (the number of "words" I want to get back) is appropriate. Thinking of it as "let's see, there are two things I want, and maybe some leftover junk, and that adds up to 3, and maxplit takes one less than that, so I should pass 2" is unhelpfully convoluted. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-30 08:17 Message: Logged In: YES user_id=3066 Fixed in Lib/string.py revisions 1.61, 1.60.16.1, and 1.59.4.1. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-21 00:38 Message: Logged In: YES user_id=196786 By the way, the reason I ended up looking at the library docs (and docstring) for the string module was that I did a simple text search on index.html from the library reference (I'm new to Python). The first match is UserString, and the second is 4. String Services, under which can be found section 4.1 "string -- Common string operations". "string" is in a monospaced font, and looks as much like a type as a module name, so I assumed that it applied to the built-in string type. I later found the documentation for the string type in section 2.2.6.1 "String Methods". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 20:45 Message: Logged In: YES user_id=31435 Guido's right, I did print "".split.__doc__ without even considering that someone may still be doing the archaic print string.split.__doc__ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 20:30 Message: Logged In: NO Tim was looking at the doc string for the split *method* of string objects, which is correct. But the complaint was about the split *function* in the (no longer needed, but still supported) string *module*, which is indeed wrong -- still in 2.2. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2002-01-20 20:20 Message: Logged In: YES user_id=196786 Thanks for responding. The docstring was from Python 2.1.2 (Debian 2.1.2-2): Python 2.1.2 (#1, Jan 18 2002, 18:05:45) [GCC 2.95.4 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) In 2.2, it seems to be corrected: Python 2.2 (#1, Jan 8 2002, 01:13:32) [GCC 2.95.4 20011006 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> print string.split.__doc__ split(s [,sep [,maxsplit]]) -> list of strings Return a list of the words in the string s, using sep as the delimiter string. If maxsplit is given, splits into at most maxsplit words. If sep is not specified, any whitespace string is a separator. (split and splitfields are synonymous) The library documentation for 2.2 still says that maxsplit defaults to 0, though apparently it defaults to -1, so that needs to be fixed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:38 Message: Logged In: YES user_id=31435 I don't know which version of Python they're using, but the docstring doesn't match what's claimed here in 2.0.1, 2.1 or 2.2. Assigned to Fred for resolution (probably "Fixed"). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-20 07:05 Message: Logged In: NO The docs and docstring seems wrong; the behavior is correct. maxsplit is the number of *separators* recognized; it defaults to -1. specifying maxsplit=0 makes it a no-op. --Guido (can't log in right now) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505997&group_id=5470 From noreply@sourceforge.net Wed Jan 30 21:26:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 13:26:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-510910 ] File inheritance across exec/spawn Message-ID: Bugs item #510910, was opened at 2002-01-30 13:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: File inheritance across exec/spawn Initial Comment: For 2.3, I added a new tempfile.TemporaryFile implementation for Windows that (among other good things) arranges that spawned processes will no longer inherit the temp files' underlying open file descriptors. There are multiple reasons for doing so on Windows, and one that's "an issue" across all platforms is security. Temp files may (will, AFAICT) still get inherited on other platforms. And inheriting open files of other kinds may still be an issue on all platforms. Guido sez (from email): """ This is exactly what happens on Unix, I'm afraid. Is there a way around that? Across fork(), I think it's fair (might be intentional). Across exec(), I think there's no point. We should use fcntl() with F_SETFD to set the FD_CLOEXEC bit. """ There is no fork on Windows, so life is simpler there; OTOH, there's no FD_CLOEXEC bit on Windows either, so life is harder there if we want to extend this to other files. I'm inclined to think we should stick to setting policy only for temp files; *we* create them, and the user has no control over how we create them. For files the user opens themself, they can get at FD_CLOEXEC (on platforms supporting it) from Python. They can also get at O_NOINHERIT on Windows in 2.3 (when using os.open()). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470 From noreply@sourceforge.net Wed Jan 30 22:45:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 14:45:41 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-510394 ] Add base classes for numeric types Message-ID: Feature Requests item #510394, was opened at 2002-01-29 14:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510394&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add base classes for numeric types Initial Comment: Create a class hierarchy for numeric types (similar to the structure for exceptions) so that the following work: issubclass(int,numeric)==1 issubclass(int,real)==1 issubclass(complex,real)==0 isinstance( 3.14, real ) == 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510394&group_id=5470 From noreply@sourceforge.net Wed Jan 30 22:45:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 14:45:56 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-510384 ] Separate Scope for List Comprehensions Message-ID: Feature Requests item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510384&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:34 Message: Logged In: NO Sorry, the bug that was fixed was about global scope. This was discussed when list comprehensions were designed, and it was a conscious decision that won't be changed. It's the same as for regular for loops. --Guido (still can't log in) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:33 Message: Logged In: NO Oops, I misread your complaint. The bug that was fixed was that sometimes the variables end up in the *global* scope. This was discussed when it was designed and it was decided to do it this way. It's similar to what a regular for loop does: for i in range(10): pass print i prints 10. I'll reject this when I can log in to SF again. --Guido (again) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-01-30 08:20 Message: Logged In: YES user_id=80475 I verified that this has NOT been fixed in Python 2.2: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> i=10 >>> temp = [str(i) for i in range(5)] >>> print i 4 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:52 Message: Logged In: NO This is Guido; I can't log in here on the road. I believe this has been fixed in Python 2.2, and possibly in 2.1.2. Can you check that? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510384&group_id=5470 From noreply@sourceforge.net Thu Jan 31 05:41:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 21:41:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 07:25:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Jan 2002 23:25:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-511073 ] urllib problems Message-ID: Bugs item #511073, was opened at 2002-01-30 23:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511073&group_id=5470 Category: Macintosh Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Yair Benita (ybenita) Assigned to: Jack Jansen (jackjansen) Summary: urllib problems Initial Comment: when using urllib.urlopen("url") and then reading the file with handle.read() i get only parts of pages. it works for short webpages but if i use it to download large pages it always come too short. To me it looks that it tries to read the file before it is downloaded. Jack Jansen's said: MacPython may do short reads on sockets. I've always maintained that this was correct (which reasoning was quietly accepted by everyone here), but last year I finally admitted that it may actually be incorrect (which was again quietly accepted:-) example: x=urllib.urlopen("http://www.ebi.ac.uk/cgi-bin/emblf etch?db=embl&format=fasta&style=raw&id=AB002 378") print x.read() compare the file downloaded by any html browser and the file from macpython. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511073&group_id=5470 From noreply@sourceforge.net Thu Jan 31 09:32:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 01:32:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:32 Message: Logged In: YES user_id=38388 This is a distutils sort of bug: if you don't specify a package version number, distutils uses '?' instead. Unfortunately, some OSes don't handle '?' in filenames too well and this is probably what you are seeing here. The fix is simple: define a version number in setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 09:33:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 01:33:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-510218 ] strftime() gets timezone wrong Message-ID: Bugs item #510218, was opened at 2002-01-29 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510218&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Greg Ward (gward) >Assigned to: M.-A. Lemburg (lemburg) Summary: strftime() gets timezone wrong Initial Comment: Platform: Debian Linux (sid/unstable) glibc 2.2.4 Python 2.2 Python's time.strftime() gets the timezone wrong in various creative ways. The timezone variable is set correctly: >>> time.timezone 18000 (That's 5 hours behind UTC, which is correct.) However, the %z and %Z format codes are inconsistent, and one or the other is always wrong: >>> time.strftime("%H:%M %z (%Z)", time.localtime(time.time())) '11:25 +0000 (EST)' >>> time.strftime("%H:%M %z (%Z)", time.gmtime(time.time())) '16:25 +0000 (EST)' %z seems to ignore the fact that I'm not in UTC; %Z is the opposite. Note that the "date" command (from GNU shellutils 2.0.11) gets it right in both cases: $ date +"%H:%M:%S %z (%Z)" 11:27:18 -0500 (EST) $ date --utc +"%H:%M:%S %z (%Z)" 16:27:20 +0000 (UTC) The obvious next step is to write a little C program to see if libc or Python is broken -- ie. is the "date" command doing special magic here? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:33 Message: Logged In: YES user_id=38388 Closing the report. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-29 09:44 Message: Logged In: YES user_id=38388 The time integer you pass into strftime() doesn't carry along any timezone information, so strftime() has to make some assumption as to what it is dealing with. The default assumption naturally is local time and that's what strftime() uses. Time zones simply don't work with non-local times. I'd suggest to close this as 'not a bug'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510218&group_id=5470 From noreply@sourceforge.net Thu Jan 31 13:13:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 05:13:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop Message-ID: Bugs item #496873, was opened at 2001-12-26 13:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 Category: Type/class unification Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: bixentxo (bixentxo) Assigned to: Anthony Baxter (anthonybaxter) Summary: cPickle / time.struct_time loop Initial Comment: The following code produces and endless loop on python 2.2 ( ok on python 2.1 ). The file being saved by cPickle.dump grows indefinetely. ----------------------------- import time, cPickle created = time.localtime() fd = open('/tmp/bla.pickle','w') cPickle.dump(created,fd) [...endless loop... ] ---------------------------------------------------------------------- Comment By: Simo Salminen (frangen) Date: 2002-01-31 05:13 Message: Logged In: YES user_id=291461 os.stat results cant be pickled either. >>> pickle.dump(os.stat('.'), open('foo', 'w')) Traceback (most recent call last): File "", line 1, in ? File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", line 969, in dump Pickler(file, bin).dump(object) File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", line 185, in save tup = reduce() File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", line 56, in _reduce state = base(self) TypeError: constructor takes exactly 13 arguments (10 given) ---------------------------------------------------------------------- Comment By: bixentxo (bixentxo) Date: 2001-12-27 12:31 Message: Logged In: YES user_id=395354 As for me, it is not a problem anymore as I found the 'tuple' solution straight away. It is not that I needed pickling struct_time is that I had no reason why not doing it. Only that it DID break my code. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-27 10:02 Message: Logged In: YES user_id=31435 Re "does anybody need to pickle time structs?", I think a better question is "does anybody pickle time.localtime() results?". The existence of the bug report suggests yes, and the OP is right that this worked in 2.1 (and 2.0, and ...). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 08:32 Message: Logged In: YES user_id=6380 Actually, the bug was in copy_reg._reduce: it was possible that this would not make any progress, returning an instance of the same type that it was passed, thus causing the infinite recursion. I've checked in a fix that raises an exception when this situation is detected. (copy_reg.py:1.10) Now, the question is, does anybody need to pickle time structs? I would recommend converting them into a tuple before pickling: pickle.dumps(tuple(time.localtime())) works fine. The statvfs issue was an unrelated bug; I've checked in a fix for that too. (posixmodule.c:2.217) Both are 2.2.1 candidates (I only noted this in the posixmodule.c CVS checkin message by mistake). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-27 06:06 Message: Logged In: YES user_id=6380 It gets in an infinite loop with pickle too, so I think this is definitely a bug in the magical type used for localtime. The stacktrack looks like this: File "/usr/local/lib/python2.2/pickle.py", line 370, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 215, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 241, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 221, in save f(self, object) repeated an infinite number of times. Note that we should look at the other objects that use structseq.c/h too. pickle.dumps(os.stat("/")) gives TypeError: constructor takes exactly 13 arguments (10 given) pickle.dumps(os.statvfs("/")) gives pickle.PicklingError: Can't pickle : it's not the same object as posix.statvfs_result Looks like a variety of bugs. :-( ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-27 03:50 Message: Logged In: YES user_id=6656 Another factoid: if you back out the change that renamed the "struct_time" type to "time.struct_time", the crash goes away, to be replaced with cPickle.PicklingError: Can't pickle : it's not found as __builtin__.struct_time so I suspect this bug has been lurking for some time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-26 22:06 Message: Logged In: YES user_id=31435 Boosted priority, assigned to Guido. A stack fault is faster to produce via the one-liner cPickle.dumps(time.localtime()) There's unbounded recursion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496873&group_id=5470 From noreply@sourceforge.net Thu Jan 31 15:22:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 07:22:35 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-510384 ] Separate Scope for List Comprehensions Message-ID: Feature Requests item #510384, was opened at 2002-01-29 14:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510384&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Separate Scope for List Comprehensions Initial Comment: The variables in a list comprehension should not be in the enclosing scope. i=10 temp = [str(i) for i in range(5)] print i Should print 10 instead of 4. Implement the above as: i=10 def _listcomp(): for i in range(5): yield str(i) temp = list(_listcomp()) print i Note, I timed the difference between the existing and proposals implementations and found only a 4% decrease in speed. In case someone is already relying on the list comprehension variables being in the local scope, a deprecation warning or from __future__ in warranted. Also note, this implementation leaves open the possibility of creating generator comprehensions so that temp=[yield str(i) for i in range(5)] creates the same code as above except that the final 'list' coercion is eliminated: temp=_listcomp ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:34 Message: Logged In: NO Sorry, the bug that was fixed was about global scope. This was discussed when list comprehensions were designed, and it was a conscious decision that won't be changed. It's the same as for regular for loops. --Guido (still can't log in) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 11:33 Message: Logged In: NO Oops, I misread your complaint. The bug that was fixed was that sometimes the variables end up in the *global* scope. This was discussed when it was designed and it was decided to do it this way. It's similar to what a regular for loop does: for i in range(10): pass print i prints 10. I'll reject this when I can log in to SF again. --Guido (again) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-01-30 08:20 Message: Logged In: YES user_id=80475 I verified that this has NOT been fixed in Python 2.2: Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> i=10 >>> temp = [str(i) for i in range(5)] >>> print i 4 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-30 07:52 Message: Logged In: NO This is Guido; I can't log in here on the road. I believe this has been fixed in Python 2.2, and possibly in 2.1.2. Can you check that? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510384&group_id=5470 From noreply@sourceforge.net Thu Jan 31 15:46:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 07:46:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-31 07:46 Message: Logged In: YES user_id=11105 I thought this bug was fixed before 2.2 final... Where can I check out StandaloneZODB so that I can look into it? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:32 Message: Logged In: YES user_id=38388 This is a distutils sort of bug: if you don't specify a package version number, distutils uses '?' instead. Unfortunately, some OSes don't handle '?' in filenames too well and this is probably what you are seeing here. The fix is simple: define a version number in setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 15:54:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 07:54:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-31 07:54 Message: Logged In: YES user_id=11105 Ok, I found it. Yup, I was right. The distutils-bug *is* fixed, here's the patch for Standalone's setup.py: RCS file: /cvs-repository/StandaloneZODB/setup.py,v retrieving revision 1.10 diff -c -r1.10 setup.py *** setup.py 21 Jan 2002 16:47:01 -0000 1.10 --- setup.py 31 Jan 2002 15:51:00 -0000 *************** *** 115,121 **** ) setup(name="BTrees", ! version="?", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, --- 115,121 ---- ) setup(name="BTrees", ! version="XXX", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, I'll mark the bug as invalid. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:46 Message: Logged In: YES user_id=11105 I thought this bug was fixed before 2.2 final... Where can I check out StandaloneZODB so that I can look into it? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:32 Message: Logged In: YES user_id=38388 This is a distutils sort of bug: if you don't specify a package version number, distutils uses '?' instead. Unfortunately, some OSes don't handle '?' in filenames too well and this is probably what you are seeing here. The fix is simple: define a version number in setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 16:22:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 08:22:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-511261 ] WIN32 os.path.normpath('./') incorrect Message-ID: Bugs item #511261, was opened at 2002-01-31 08:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511261&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Steven Knight (stevenknight) Assigned to: Nobody/Anonymous (nobody) Summary: WIN32 os.path.normpath('./') incorrect Initial Comment: os.path.normpath() on WIN32 systems returns a null string for . followed by a directory separator: >>> os.path.normpath('./') '' >>> os.path.normpath('.\') '' >>> os.path.normpath('.') '.' >>> Contrast with what happens on Linux: >>> os.path.normpath('./') '.' >>> os.path.normpath('.') '.' >>> Sorry, I don't have a later version than 2.1.1 available to check whether this is fixed in a later version, but I did do a search for other reports of this bug and found none. --SK ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511261&group_id=5470 From noreply@sourceforge.net Thu Jan 31 17:35:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 09:35:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-510868 ] Solaris 2.7 make chokes. Message-ID: Bugs item #510868, was opened at 2002-01-30 11:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sharad Satsangi (sharadinfozen) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 2.7 make chokes. Initial Comment: I'm building python2.2 on a Solaris2.7 box, an Ultra- 10. I get a segmentation fault error at 'xreadlines' when I try the make. I am not sure why. Logs of the configuration script & make are attached. (in one concatenated file, I could not tell how to upload more than one file). Any help will be greatly appreciated. thanks! -sharad. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-01-31 09:35 Message: Logged In: YES user_id=21627 Can you attach to Python with gdb and see why it crashes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470 From noreply@sourceforge.net Thu Jan 31 19:17:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 11:17:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-31 11:17 Message: Logged In: YES user_id=12800 I don't think you're using the right cvs branch on your checkout. You should be using StandaloneZODB-1_0-branch. On that branch, setup.py will have a revision 1.9.4.4 which should have the correct values. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:54 Message: Logged In: YES user_id=11105 Ok, I found it. Yup, I was right. The distutils-bug *is* fixed, here's the patch for Standalone's setup.py: RCS file: /cvs-repository/StandaloneZODB/setup.py,v retrieving revision 1.10 diff -c -r1.10 setup.py *** setup.py 21 Jan 2002 16:47:01 -0000 1.10 --- setup.py 31 Jan 2002 15:51:00 -0000 *************** *** 115,121 **** ) setup(name="BTrees", ! version="?", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, --- 115,121 ---- ) setup(name="BTrees", ! version="XXX", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, I'll mark the bug as invalid. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:46 Message: Logged In: YES user_id=11105 I thought this bug was fixed before 2.2 final... Where can I check out StandaloneZODB so that I can look into it? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:32 Message: Logged In: YES user_id=38388 This is a distutils sort of bug: if you don't specify a package version number, distutils uses '?' instead. Unfortunately, some OSes don't handle '?' in filenames too well and this is probably what you are seeing here. The fix is simple: define a version number in setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 20:27:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 12:27:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-01-31 12:27 Message: Logged In: YES user_id=11105 Maybe the right branch of StandaloneZODB fixes this particular problem, the branch did at least reproduce the problem;-) The question is: should distutils check if the version number contains characters disallowed in filenames (on windows, are there any for *nix or Mac?), and construct a filename without embedded version number in these cases? I have reopened the bug, please comment. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-31 11:17 Message: Logged In: YES user_id=12800 I don't think you're using the right cvs branch on your checkout. You should be using StandaloneZODB-1_0-branch. On that branch, setup.py will have a revision 1.9.4.4 which should have the correct values. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:54 Message: Logged In: YES user_id=11105 Ok, I found it. Yup, I was right. The distutils-bug *is* fixed, here's the patch for Standalone's setup.py: RCS file: /cvs-repository/StandaloneZODB/setup.py,v retrieving revision 1.10 diff -c -r1.10 setup.py *** setup.py 21 Jan 2002 16:47:01 -0000 1.10 --- setup.py 31 Jan 2002 15:51:00 -0000 *************** *** 115,121 **** ) setup(name="BTrees", ! version="?", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, --- 115,121 ---- ) setup(name="BTrees", ! version="XXX", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, I'll mark the bug as invalid. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:46 Message: Logged In: YES user_id=11105 I thought this bug was fixed before 2.2 final... Where can I check out StandaloneZODB so that I can look into it? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:32 Message: Logged In: YES user_id=38388 This is a distutils sort of bug: if you don't specify a package version number, distutils uses '?' instead. Unfortunately, some OSes don't handle '?' in filenames too well and this is probably what you are seeing here. The fix is simple: define a version number in setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 20:35:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 12:35:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-220993 ] Installation flaky with multiple installers, old versions Message-ID: Bugs item #220993, was opened at 2000-11-01 05:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Michael Hudson (mwh) Summary: Installation flaky with multiple installers, old versions Initial Comment: Installation tends to have problems when there are old installations present, especially when a different user is doing the new installation. In particular, it appears that the chmod() done in 'copy_file()' (as a result of the "install" command attempting to preserve the mode of files from the build tree) fails, because you can't chmod() a file owned by somebody else. Paul Dubois suggests that simply unlinking the target file before doing the copy should work. I think he's right, but need to think about it and test it a bit first. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-01-31 12:35 Message: Logged In: YES user_id=11375 This bit David Binger today, so I finally dug in and fixed it. Patch attached for a sanity-check. (2.2 bugfix candidate) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 08:07 Message: Logged In: YES user_id=6656 I'll have a look at this, as I've already assigned some installation related bugs to myself. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-09-20 11:41 Message: Logged In: YES user_id=11375 I think unlinking first is the right thing to do, having just run into another problem that seems to be caused by this. Installing *.so files to an NFS partition messed up other people, I think because they had the *.so file loaded into memory and the kernel's VM got confused. (That's the theory, anyway.) Bumping up the priority as a reminder to myself... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=220993&group_id=5470 From noreply@sourceforge.net Thu Jan 31 20:48:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 12:48:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-511055 ] bdist_wininst fails on StandaloneZODB Message-ID: Bugs item #511055, was opened at 2002-01-30 21:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 Category: Distutils Group: Python 2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Thomas Heller (theller) Summary: bdist_wininst fails on StandaloneZODB Initial Comment: I don't know what I'm doing (never tried anything like this before), so scream if this is stupid. From a vanilla CVS checkout of Zope Corp's StandaloneZODB, I tried (this is with Python 2.2 final): \python22\python setup.py bdist_wininst This was on Win98SE, with MSVC 6 installed. It seemed to run fine for awhile, but eventually barfed. Here's the tail end: ... LIB\BTrees copying build\lib.win32-2.2\BTrees\OIBTree.pyc -> build\bdist.win32\wininst\PLATLIB\BTrees warning: install: modules installed to 'build\bdist.win32\wininst\PLATLIB\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself changing into 'build\bdist.win32\wininst' zip -rq c:\windows\TEMP\~-1370033-3.zip . creating 'c:\windows\TEMP\~-1370033-3.zip' and adding '.' to it changing back to 'C:\Code\StandaloneZODB' creating dist\BTrees-?.win32-py2.2.exe error: dist\BTrees-?.win32-py2.2.exe: No such file or directory C:\Code\StandaloneZODB> FYI, "setup.py install" and "setup.py build" work fine from this directory. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-01-31 12:48 Message: Logged In: YES user_id=31435 I wouldn't bother, Thomas. All OSes have *some* disallowed characters (e.g., the platform path separator character is always disallowed, else a path would be ambiguous). The problem here was using "?" instead of the universally recognized "XXX" to mean "this needs more attention", and that quirk is unlikely to be common. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 12:27 Message: Logged In: YES user_id=11105 Maybe the right branch of StandaloneZODB fixes this particular problem, the branch did at least reproduce the problem;-) The question is: should distutils check if the version number contains characters disallowed in filenames (on windows, are there any for *nix or Mac?), and construct a filename without embedded version number in these cases? I have reopened the bug, please comment. ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2002-01-31 11:17 Message: Logged In: YES user_id=12800 I don't think you're using the right cvs branch on your checkout. You should be using StandaloneZODB-1_0-branch. On that branch, setup.py will have a revision 1.9.4.4 which should have the correct values. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:54 Message: Logged In: YES user_id=11105 Ok, I found it. Yup, I was right. The distutils-bug *is* fixed, here's the patch for Standalone's setup.py: RCS file: /cvs-repository/StandaloneZODB/setup.py,v retrieving revision 1.10 diff -c -r1.10 setup.py *** setup.py 21 Jan 2002 16:47:01 -0000 1.10 --- setup.py 31 Jan 2002 15:51:00 -0000 *************** *** 115,121 **** ) setup(name="BTrees", ! version="?", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, --- 115,121 ---- ) setup(name="BTrees", ! version="XXX", packages=["BTrees", "BTrees.tests"], ext_modules = [oob, oib, iib, iob], author = zope_corp, I'll mark the bug as invalid. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-31 07:46 Message: Logged In: YES user_id=11105 I thought this bug was fixed before 2.2 final... Where can I check out StandaloneZODB so that I can look into it? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 01:32 Message: Logged In: YES user_id=38388 This is a distutils sort of bug: if you don't specify a package version number, distutils uses '?' instead. Unfortunately, some OSes don't handle '?' in filenames too well and this is probably what you are seeing here. The fix is simple: define a version number in setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511055&group_id=5470 From noreply@sourceforge.net Thu Jan 31 21:09:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 13:09:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-510868 ] Solaris 2.7 make chokes. Message-ID: Bugs item #510868, was opened at 2002-01-30 11:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sharad Satsangi (sharadinfozen) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 2.7 make chokes. Initial Comment: I'm building python2.2 on a Solaris2.7 box, an Ultra- 10. I get a segmentation fault error at 'xreadlines' when I try the make. I am not sure why. Logs of the configuration script & make are attached. (in one concatenated file, I could not tell how to upload more than one file). Any help will be greatly appreciated. thanks! -sharad. ---------------------------------------------------------------------- >Comment By: Sharad Satsangi (sharadinfozen) Date: 2002-01-31 13:09 Message: Logged In: YES user_id=443851 I did try gdb on the python binary, but got nothing interesting (you can see in the file gdbpyth). thanks, -sharad. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-31 09:35 Message: Logged In: YES user_id=21627 Can you attach to Python with gdb and see why it crashes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470 From noreply@sourceforge.net Thu Jan 31 22:21:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 14:21:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-509288 ] package_dir paths not converted Message-ID: Bugs item #509288, was opened at 2002-01-27 12:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: package_dir paths not converted Initial Comment: If you supply a package_dir dictionary to setup(), as the most recent setup.py for Numeric does, the pathnames in this dictionary are used as-is, in stead of going through a URL-to-local-pathname-convention mapping, as all other pathnames do. I don't understand enough of the architecture to know where to do this conversion, so if someone else could have a look.... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-01-31 14:21 Message: Logged In: YES user_id=45365 Your patch works wonderfully! Please check it in... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-28 08:20 Message: Logged In: YES user_id=11105 Oops, apparently package_dir can be None instead of beeing a dictionatry. Updated the patch (patch2.txt). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-01-28 01:41 Message: Logged In: YES user_id=11105 Jack, does this patch fix your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=509288&group_id=5470