From noreply@sourceforge.net Tue Oct 1 00:23:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 16:23:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows) Message-ID: Bugs item #216289, was opened at 2000-10-06 19:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Later Priority: 3 Submitted By: Tim Peters (tim_one) Assigned to: Fredrik Lundh (effbot) Summary: Programs using Tkinter sometimes can't shut down (Windows) Initial Comment: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS. In my case, I was running IDLE via python ../tool/idle/idle.pyw from a DOS box in my PCbuild directory. Win98SE. *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging. As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap. -----Original Message----- From: Joseph Stubenrauch Sent: Friday, October 06, 2000 9:23 PM To: tutor@python.org Subject: Re: [Tutor] Python 1.6 BUG Strange, I have been experiencing the same bug myself. Here's the low down for me: Python 1.6 with win95 I am running a little Tkinter program The command line I use is simply: "python foo.py" About 25-35% of the time, when I close the Tkinter window, DOS seems to "freeze" and never returns to the c:\ command prompt. I have to ctrl-alt-delete repeatedly and shut down "winoldapp" to get rid of the window and then shell back into DOS and keep working. It's a bit of a pain, since I have the habit of testing EVERYTHING in tiny little stages, so I change one little thing, test it ... freeze ... ARGH! Change one more tiny thing, test it ... freeze ... ARGH! However, sometimes it seems to behave and doesn't bother me for an entire several hour session of python work. That's my report on the problem. Cheers, Joe ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-30 16:23 Message: Logged In: NO i would like to know some moves ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-08-21 17:08 Message: Logged In: YES user_id=143340 Hi, tried wrapping the WaitForSingleObject() with if (consolePtr- >toWrite) { ... as suggested. Solves the problem for me in debug and release builds (without thread support). What is "the tcl83.dll from www.tcl.tk", what changes does it include? cheers, John. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2002-08-16 16:03 Message: Logged In: YES user_id=148444 I downloaded and tested the tcl83.dll from www.tcl.tk with Python 2.2.1 on Win98SE using my BugDemo.py script from a related bug report [231207]. Several test runs showed that a problem still exists. The app hangs until Winopldapp is killed, however this leaves tcl83.dll in use. The problem does not occur on every execution. Some types of activity seem to provoke the hang, for instance, minimizing and maximizing the window seems to increase the change that it will hang on exit. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-08-16 14:53 Message: Logged In: YES user_id=7549 Whoop, error in the patch.. consoleMutex might not need to be locked. It could cause a new dead-lock. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-08-16 14:41 Message: Logged In: YES user_id=7549 >It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c' >at about line 527: >WaitForSingleObject(consolePtr->writeThread, INFINITE); Jeff, this might need the same attention the pipe reader thread got for that [exec] memory leak bug. I think ConsoleWriterThread() should use WaitForMultipleObjects instead of WaitForSingleObject with a second event handle used to single a fall-out like the pipe reader thread does. It appears that ConsoleCloseProc() has no way to signal the writer thread to close at all. This doesn't address the blocking WriteFile() in ConsoleWriterThread(), though. Is it blocking there, too? Sorry for the large post. I'm given the option to attach a file. Index: tclWinConsole.c ============================================= ====================== RCS file: /cvsroot/tcl/tcl/win/tclWinConsole.c,v retrieving revision 1.7 diff -c -r1.7 tclWinConsole.c *** tclWinConsole.c 15 Jan 2002 17:55:30 -0000 1.7 --- tclWinConsole.c 16 Aug 2002 21:31:56 -0000 *************** *** 79,84 **** --- 79,87 ---- HANDLE startWriter; /* Auto-reset event used by the main thread to * signal when the writer thread should attempt * to write to the console. */ + HANDLE stopWriter; /* Auto-reset event used by the main thread to + * signal when the writer thread should + * terminate. */ HANDLE startReader; /* Auto-reset event used by the main thread to * signal when the reader thread should attempt * to read from the console. */ *************** *** 516,522 **** */ Tcl_MutexLock(&consoleMutex); ! TerminateThread(consolePtr->writeThread, 0); /* * Wait for the thread to terminate. This ensures that we are --- 519,525 ---- */ Tcl_MutexLock(&consoleMutex); ! SetEvent(consolePtr->stopWriter); /* * Wait for the thread to terminate. This ensures that we are *************** *** 1134,1149 **** { ConsoleInfo *infoPtr = (ConsoleInfo *)arg; HANDLE *handle = infoPtr->handle; DWORD count, toWrite; char *buf; for (;;) { /* * Wait for the main thread to signal before attempting to write. */ ! WaitForSingleObject(infoPtr->startWriter, INFINITE); buf = infoPtr->writeBuf; toWrite = infoPtr->toWrite; --- 1137,1163 ---- { ConsoleInfo *infoPtr = (ConsoleInfo *)arg; + HANDLE events[2]; HANDLE *handle = infoPtr->handle; DWORD count, toWrite; char *buf; + events[0] = infoPtr->stopWriter; + events[1] = infoPtr->startWriter; + for (;;) { + DWORD dwWait; + /* * Wait for the main thread to signal before attempting to write. */ ! dwWait = WaitForMultipleObjects(events, 2, FALSE, INFINITE); ! ! if (dwWait != (WAIT_OBJECT_0 + 1)) { ! /* either the stop event or some other error, so exit */ ! return 0; ! } buf = infoPtr->writeBuf; toWrite = infoPtr->toWrite; *************** *** 1251,1256 **** --- 1265,1271 ---- if (permissions & TCL_WRITABLE) { infoPtr->writable = CreateEvent(NULL, TRUE, TRUE, NULL); infoPtr->startWriter = CreateEvent(NULL, FALSE, FALSE, NULL); + infoPtr->stopWriter = CreateEvent(NULL, FALSE, FALSE, NULL); infoPtr->writeThread = CreateThread(NULL, 8000, ConsoleWriterThread, infoPtr, 0, &id); } ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-08-16 11:56 Message: Logged In: YES user_id=72656 I'm finding it a bit hard to reproduce, and now not at all. Could people please try replacing their current tcl83.dll with the one at http://www.tcl.tk/tcl83.dll. The sig on it is: 634880 Aug 16 10:53 tcl83.dll (md5) b35628568ddc4afed4f675d2d9a50faf tcl83.dll I can't hang anymore with python 2.2.1 at the Win98 command prompt with: python \Python22\Tools\idle\idle.pyw ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-08-16 10:50 Message: Logged In: YES user_id=72656 johnny - That actually helps a lot and fairly clearly indicates the source of this hanging problem. To give more context to that area, this is in the final shutdown code where it is (obviously) shutting down the console I/O. The reader is shutdown without a check for more input (why, we are exiting?), so there is no issue there. The writer however wants to make sure that the console output channel is drained before exit. A blocking channel that is not being flushed will cause a hang. So the question is, what is the stdio setup for Tcl in Py/Tkinter? That should be examined to see whether stdio is clear to flush on exit. Perhaps you can also help with more debugging. Could you wrap the problematic WaitForSingleObject call with if (consolePtr->toWrite) { ... and perhaps also print out what to write. It may be that blocking output isn't the problem at all, but rather that we are never receiving the signal on consolePtr->writable (usually done in the writer thread). The consolePtr->toWrite check will at least ensure flushed channels do not enter this potential hanging state. ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-08-16 07:16 Message: Logged In: YES user_id=143340 I have dug out the setup I used previously and, apart from using Python 2.2 instead of 2.0.1, have had a go at reproducing my previous results. With a debug build of Tcl/Tk and threads disabled I have managed to get this stack trace when it locks on exit (after doing a break): ConsoleCloseProc(int * 0x006a0ae4, Tcl_Interp * 0x00000000) line 527 + 17 bytes TclFinalizeIOSubsystem() line 241 + 20 bytes Tcl_FinalizeThread() line 911 Tcl_Finalize() line 812 DllMain(HINSTANCE__ * 0x00970000, unsigned long 0x00000000, void * 0x00000001) line 197 TCL83! _DllMainCRTStartup@12 + 80 bytes KERNEL32! bff7ddd6() KERNEL32! bff8d123() 8176b5fc() It is hanging up in ConsoleCloseProc() in 'tclWinConsole.c' at about line 527: WaitForSingleObject(consolePtr->writeThread, INFINITE); I tried changing the timeout from INFINITE to 100ms and testing the return value for WAIT_TIMEOUT. Sure enough it occasionaly printed a message (and didn't lock-up). Don't know if this helps. Will try to reproduce the double free problem in the threaded build later, cheers, John. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-15 07:19 Message: Logged In: YES user_id=6380 Just a note so I won't forget this: Jeff Hobbs once said the code to look at is tk/generic/tkConsole.c:Tk_InitConsoleChannels ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-08-15 06:23 Message: Logged In: YES user_id=7549 Hi John, I have seen Tcl extension DLLs that set exit handlers get called by Tcl after they were torn-down. NT and Win9x seem to be a bit different in the order of what DLLs get torn-down. here's a note from some old code of mine: #ifdef __WIN32__ // It can happen that the HEAP could have already been unloaded // from an awkward teardown caused by a Ctrl+C or other. Win32 // seems to do a teardown in reverse order and by the time Tcl // knows what's going on and Tcl_Finalize calls the exit // handlers, this extension's data (heap?) has already been // unloaded by the OS. Do a quick legal check on the pointer // first. // if (IsBadReadPtr(adapt, sizeof(T *))) return; #endif what's the back/stacktrace? who is calling Tcl_FinalizeNotifier? And had anyone called it before during the shutdown phase? I can't say with much confidence that this is happening here, too. Maybe.. Could Tk be telling Tcl shutdown? That's sort of backwards, if so. I run w2k here, so I can't help in debugging from a test case. tclsh with a threaded build doesn't even call Tcl_Finalize to avoid all this! ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2002-08-15 06:09 Message: Logged In: YES user_id=79902 Firstly, on the matter of threads. Tcl/Tk on Windows uses threads internally even in non-threaded builds. That's Windows for you (in particular, you can get calls parachuted in from completely separate threads with relatively little warning. Also, you need threaded helpers to handle non-blocking waiting on some kinds of objects.) It's a bit hard to work out if the problem's been fixed without a stack-trace (preferably with debugging symbols enabled so that we can see what the function names and arguments to those functions are.) I have no chance of replicating this bug here (I'm currently running IRIX, but also have some access to Solaris and Linux...) ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-08-15 05:15 Message: Logged In: YES user_id=143340 Hi to davygrvy, my fix isn't for a thread related (deadlock) type problem - it is a fix for a double free type problem which is presumably screwing up the heap and causing the C runtime to hang. It *is* with a threaded build (THREADDEFINES = - DTCL_THREADS=1) which I think I enabled because I was using 'after' and it didn't work unless threading was enabled - but I may be mis-remembering here! Also, I ended up doing all this with the debug build and found the -GZ flag useful - in fact it pointed out the fact that there was a problem with the heap. It is worth noting that I have only seen this on Win98 and that using 'pythonw.exe' did *not* prevent this from happening, regards John. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-14 18:00 Message: Logged In: YES user_id=6380 AFAIK we never distributed a threaded build. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-08-14 17:01 Message: Logged In: YES user_id=7549 To johnnypops, Where in Tcl_FinalizeNotifier() is the dead-lock occuring and is this with a threaded build of Tcl? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-02 12:39 Message: Logged In: YES user_id=31435 Jeff, a long time ago Fredrik Lundh said he was able to reproduce this with a short wish script (no Python, no Tkinter, just Tcl/Tk + wish). I'm reassigning this to /F in the hopes he'll remember how. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-07-02 11:55 Message: Logged In: YES user_id=72656 I appreciate that many others see this is a problem in embedding Tcl, but without any clear way to reproduce this in Tcl/Tk itself, it's very hard for me to fix it. I don't think that there is anything done in 8.4 to fix this that I recall, but if someone finds that the problem "goes away" with 8.4, please report that. For those of course that experience this with python, the simple and "correct" work-around is to launch with pythonw.exe instead of python.exe. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-26 10:40 Message: Logged In: NO According to http://tcl.activestate.com ActiveTcl 8.4.0 is now available for download. It is new as of June 24. I don't know whether this will solve our problems or not, but it's worth looking into. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-19 06:36 Message: Logged In: NO I just downloaded Ruby 1.6.6 for Windows, which also uses Tcl/Tk 8.3 and I experience exactly the same problem there. So this is definitely a Tcl problem (but we know that already). ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-06-07 12:01 Message: Logged In: YES user_id=143340 Hmmm. I run a Python Tcl/Tk application several times every day - the very application that prompted my bug-hunt. I do use "pythonw.exe" to launch it, but it used to hang almost as badly as "python.exe". Whilst developing this app I used "python.exe" and experienced no hang-ups. The Tcl guys point out that this bug is only one of several possible causes of the hang-up, maybe you are just out of luck. The patch has fixed the problem on three Win98 machines, all of which exhibited the problem before updating the DLLs. One thought - are you sure there weren't multiple copies of the tcl83.dll and tk83.dll files? My (only) copies were in "D:\python20\DLLs" good luck, John. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-06-03 11:55 Message: Logged In: YES user_id=72656 providing Tim with a fixed DLL exactly according to John Popplewell's patch did not fix the problem for him. That makes it seem fishy that John really didn't see the problem any more. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-06-03 09:59 Message: Logged In: YES user_id=31435 I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from Tcl/Tk 8.3.2) with newer matched sets from A) PythonWare's py21 distribution (Tcl/Tk 8.3.3). and again from B) ActiveState's Tcl/Tk 8.3.4. All the symptoms originally reported here persisted on Win98SE despite that. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 06:57 Message: Logged In: NO I am new to Python and encountered this bug on my very first Tkinter application. It persists in Python 2.2.1 under Windows Me. Needless to say, it makes a bad first impression. Basically, this thread says that Tkinter has been broken for a year and a half on a popular platform at a time when Python is trying to expand its user base. Hopefully, this bug will be corrected soon. If Tcl/Tk 8.4 is not released shortly you might try repackaging Tkinter for Win32 with an earlier version of Tcl/Tk, such as 8.0, that doesn't encounter this problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 19:36 Message: Logged In: YES user_id=6380 The proper action is to wait until Tcl 8.3.5 is released, and then shaming someone else in providing you with a set of Windowsbinaries for Tcl. You may also ask Hobbs if there's a Windows project file to build Tcl/Tk for Windows. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-03-11 18:31 Message: Logged In: YES user_id=72656 I did end up back-porting this to the 8.3.4+ Tcl CVS on 2002-02-25, which means it will be in an eventual 8.3.5. It is already in the release 8.4 alpha series. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-09 17:50 Message: Logged In: YES user_id=31435 Back to Guido: Do you think you know what the proper action is? (You said that's why you reopened it, and there's been no new info here since then.) ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-02-25 16:55 Message: Logged In: YES user_id=143340 I knew I wasn't getting to the heart of it .... Almost a one-liner! It has been seriously spoiling my (otherwise crash free) Python experience on Win9x - hope it gets fixed soon. cheers, John. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-25 15:39 Message: Logged In: YES user_id=6380 Reopened until we know what the proper action is. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2002-02-25 15:32 Message: Logged In: YES user_id=72656 This is mostly correct, and is fixed in the 8.4 Tcl sources already (I guess we can backport this). This was mentioned in SF Tcl bug (account for chopped URL): https://sourceforge.net/tracker/? func=detail&aid=217982&group_id=10894&atid=110894 and the code comment is: /* * Only finalize the notifier if a notifier was installed in the * current thread; there is a route in which this is not * guaranteed to be true (when tclWin32Dll.c:DllMain() is called * with the flag DLL_PROCESS_DETACH by the OS, which could be * doing so from a thread that's never previously been involved * with Tcl, e.g. the task manager) so this check is important. * * Fixes Bug #217982 reported by Hugh Vu and Gene Leache. */ if (tsdPtr == NULL) { return; } ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-02-25 14:41 Message: Logged In: YES user_id=143340 This one has been torturing me for a while. Managed to track it down to a problem inside Tcl. For the Tcl8.3.4 source distribution the problem is in the file win/tclWinNotify.c void Tcl_FinalizeNotifier(ClientData clientData) { ThreadSpecificData *tsdPtr = (ThreadSpecificData *) clientData; /* sometimes called with tsdPtr == NULL */ if ( tsdPtr != NULL ) { DeleteCriticalSection(&tsdPtr->crit); CloseHandle(tsdPtr->event); /* * Clean up the timer and messaging * window for this thread. */ if (tsdPtr->hwnd) { KillTimer(tsdPtr->hwnd, INTERVAL_TIMER); DestroyWindow(tsdPtr->hwnd); } } /* * If this is the last thread to use the notifier, * unregister the notifier window class. */ Tcl_MutexLock(¬ifierMutex); if ( notifierCount && !--notifierCount ) { UnregisterClassA( "TclNotifier", TclWinGetTclInstance()); } Tcl_MutexUnlock(¬ifierMutex); } This bodge doesn't address the underlying problem but has stopped me from tearing all my hair out, cheers, John Popplewell. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-24 15:27 Message: Logged In: YES user_id=31435 FYI, you don't need an IDE to do this -- in Win9x, hit Ctrl+Alt+Del and kill the process directly. A saner solution is to develop under Win2K, which doesn't appear to suffer this problem (the only reports I've seen, and experienced myself, came from Win9x boxes). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-10-24 01:52 Message: Logged In: NO For those who are still trapped in this bug's hell, I will gladly share the one thing that saved my sanity: WingIDE's 'Kill' command will shut down the program with apparent 100% certainty and no fear of lockups. WingIDE has its own issues, so its not a perfect solution, but if you are like me and Joe (above) who test in small iterations, then using 'Kill' to quit out of your app while testing is a workaround that may preserve your sanity. Perhaps the python gods and the Wing guys can get together and tell us how to replicate 'kill' into our code. For now, I'll use WingIDE to edit, and pythonw.exe for my final client's delivery. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 10:43 Message: Logged In: YES user_id=66570 I sometimes get bunches of these.... A tool I use (Taskinfo2000) reports that (after killing winoldap): python.exe is blocked on a mutex named OLESCELOCKMUTEX. The reported state is "Console Terminating". There appears to be only one (os) thread running. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-02 13:06 Message: Logged In: YES user_id=31435 No sign of progress on this presumed Tk/Tcl Windows bug in over 3 months, so closing it for lack of hope. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-05 21:13 Message: This was a symptom I saw while tracking down the essence of the problem reported in #131207. Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-12-12 18:00 Message: Just reproduced w/ current CVS, but didn't hang until the 8th try. http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-12 12:58 Message: Tim, can you still reproduce this with the current CVS version? There's been one critical patch to _tkinter since the 2.0 release. An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-10-15 09:47 Message: Same as I've reported earlier; it hangs in the call to Tcl_Finalize (which is called by the DLL finalization code). It's less likely to hang if I call Tcl_Finalize from the _tkinter DLL (from user code). Note that the problem isn't really Python-related -- I have stand-alone samples (based on wish) that hangs in the same way. More later. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-13 07:40 Message: Back to Tim since I have no clue what to do here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-12 10:25 Message: The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either. As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again. Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-10-07 00:37 Message: More info (none good, but some worse so boosted priority): + Happens under release and debug builds. + Have not been able to provoke when starting in the debugger. + Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up. There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show. + This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot. + These processes cannot be killed! Wintop and Process Viewer both fail to get the job done. PrcView (a freeware process viewer) itself locks up if I try to kill them using it. Process Viewer freezes for several seconds before giving up. + Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program". + The processes are not accumulating cycles. + Smells like deadlock. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470 From noreply@sourceforge.net Tue Oct 1 05:30:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 21:30:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-616019 ] list(xrange(sys.maxint / 4)) -> swapping Message-ID: Bugs item #616019, was opened at 2002-09-29 02:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint / 4)) -> swapping Initial Comment: Refer to #556025 list(xrange(1e9)) --> seg fault for the history. The test in test/test_b1.py causes OS X 10.2.1 to start swapping instantly and never stopped until I killed the process after 5 minutes. I wasn't brave enough to let it run for any longer. list(xrange(1e09)) or even list(xrange(sys.maxint)) works: Traceback (most recent call last): File "test_b1.py", line 553, in ? list(xrange(sys.maxint)) MemoryError PhysMem: 55.7M wired, 300M active, 150M inactive, 506M used, 6.19M free VM: 4.19G + 76.9M 36909(35) pageins, 1505603(200) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1157 python 9.1% 0:33.72 1 13 1186 373M+ 1.55M 160M- 2.29G+ ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2002-10-01 04:30 Message: Logged In: YES user_id=17671 OK, I added a fprintf to the NRESIZE macro and got the same results on three different platforms, but both OS X builds start swapping rather than raising a MemoryError. I guess the next place to look is PyMem_RESIZE Windows-XP-5.1.2600-SP1: Linux (glibc2.1.3): OS X 10.2.1 (gcc3): OS X 10.2.1 (gcc 2.95.2): sys.maxint: 2147483647 test_b1.py: list _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 536870912 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 16:01 Message: Logged In: YES user_id=21627 Can you please find out how much memory it tries to allocate? The easiest approach might be add a print statement; I *think* the relevant allocation should come from the NRESIZE macro - we'd need to find out what value _new_size has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 From noreply@sourceforge.net Tue Oct 1 17:25:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 01 Oct 2002 09:25:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-617110 ] SIGINT handler no longer installable. Message-ID: Bugs item #617110, was opened at 2002-10-01 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Nobody/Anonymous (nobody) Summary: SIGINT handler no longer installable. Initial Comment: After the following commands: >>> import signal >>> signal.signal(signal.SIGINT,signal.SIG_IGN) >>> print signal.getsignal(signal.SIGINT) 1 >>> Typing control-C or sending the process a SIGINT leads to a KeyboardInterrupt exception. Installing a signal handler instead of SIG_IGN doesn't help. The docs clearly state that the default handler can be overridden. Also in python 1.5.2 the above example works as I would expect - both control-C and SIGINT are ignored in that version. I'm running 2.2.1 on Solaris. I have seen the problem under Linux also. Python 2.2.1 (#1, Jul 16 2002, 15:22:16) [GCC 2.95.2 19991024 (release)] on sunos5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 From noreply@sourceforge.net Wed Oct 2 13:32:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 05:32:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-617110 ] SIGINT handler no longer installable. Message-ID: Bugs item #617110, was opened at 2002-10-01 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Nobody/Anonymous (nobody) Summary: SIGINT handler no longer installable. Initial Comment: After the following commands: >>> import signal >>> signal.signal(signal.SIGINT,signal.SIG_IGN) >>> print signal.getsignal(signal.SIGINT) 1 >>> Typing control-C or sending the process a SIGINT leads to a KeyboardInterrupt exception. Installing a signal handler instead of SIG_IGN doesn't help. The docs clearly state that the default handler can be overridden. Also in python 1.5.2 the above example works as I would expect - both control-C and SIGINT are ignored in that version. I'm running 2.2.1 on Solaris. I have seen the problem under Linux also. Python 2.2.1 (#1, Jul 16 2002, 15:22:16) [GCC 2.95.2 19991024 (release)] on sunos5 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:32 Message: Logged In: YES user_id=6656 I find this sort of thing is usually readline's fault. Is that possible here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 From noreply@sourceforge.net Wed Oct 2 14:05:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 06:05:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-617110 ] SIGINT handler no longer installable. Message-ID: Bugs item #617110, was opened at 2002-10-01 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Nobody/Anonymous (nobody) Summary: SIGINT handler no longer installable. Initial Comment: After the following commands: >>> import signal >>> signal.signal(signal.SIGINT,signal.SIG_IGN) >>> print signal.getsignal(signal.SIGINT) 1 >>> Typing control-C or sending the process a SIGINT leads to a KeyboardInterrupt exception. Installing a signal handler instead of SIG_IGN doesn't help. The docs clearly state that the default handler can be overridden. Also in python 1.5.2 the above example works as I would expect - both control-C and SIGINT are ignored in that version. I'm running 2.2.1 on Solaris. I have seen the problem under Linux also. Python 2.2.1 (#1, Jul 16 2002, 15:22:16) [GCC 2.95.2 19991024 (release)] on sunos5 ---------------------------------------------------------------------- >Comment By: Thorstein Thorsteinsson (thorstein) Date: 2002-10-02 13:05 Message: Logged In: YES user_id=587322 readline: That seems likely actually. I'm using readline both on the above installation and on the Linux installation referred to. A slightly earlier install without readline works ok: Python 2.1.1 (#3, Nov 29 2001, 17:41:42) [GCC 2.95.2 19991024 (release)] on sunos5 Also, if the Python process isn't connected to a terminal things work fine. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:32 Message: Logged In: YES user_id=6656 I find this sort of thing is usually readline's fault. Is that possible here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 From noreply@sourceforge.net Wed Oct 2 15:17:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 07:17:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-616786 ] Problems (fixes) compiling 2.2.1 on sun4 Message-ID: Bugs item #616786, was opened at 2002-09-30 23:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616786&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: Problems (fixes) compiling 2.2.1 on sun4 Initial Comment: I had a few problems compiling "Python-2.2.1" on "SunOS 4.1.4 1 sun4m" using gcc "version egcs-2.91.5" (sorry it's not my system and I had no choice). I'd guess this applies to other versions of python as well, but this is the first time I tried this. The most serious problem was in the function "PyOS_vsnprintf" in the file "Python/mysnprintf.c". For the case where HAVE_SNPRINTF is NOT #defined there is the call, len = vsprintf(buffer, format, va); But on "SunOS 4.1.4", on success "vsprintf" returns the first argument (buffer) and NOT the length of the string! I "fixed" this by adding after the above call, if (len == (int)buffer) len = strlen(buffer); I guess a better way would be to have a #ifdef for the OS but this seems to work OK for all systems. Three other source files needed minor tweaking: -- In Objects/fileobject.c at the beginning of function file_init() I needed to add the line: extern int fclose(FILE *); -- In Modules/posixmodule.c at the beginning of function posix_chroot() I needed to add the line: int chroot(); -- In Modules/xxsubtype.c at the beginning of function spam_bench() I needed to add the lines: #ifndef CLOCKS_PER_SEC # define CLOCKS_PER_SEC 1000000l /* ? */ #endif Seems like the first 2 would be OK in general. And perhaps there's an equivalent of CLOCKS_PER_SEC in some "sun4" header file but I couldn't find it. I realize supporting this antiquated operation system and "gcc" isn't a high priority, but since the changes are so minimal perhaps they could be added to save some other poor soul some headaches. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 16:17 Message: Logged In: YES user_id=21627 According to PEP 11 (http://www.python.org/peps/pep-0011.html) SunOS 4 will become unsupported in Python 2.3, and the remaining pieces will be removed in Python 2.4. If you volunteer to support the SunOS port, we can re-support it, you can then submit patches for both 2.2 and 2.3. Without a volunteer who actively maintains the port, we will have to close this report as "Won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616786&group_id=5470 From noreply@sourceforge.net Wed Oct 2 15:19:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 07:19:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-617110 ] SIGINT handler no longer installable. Message-ID: Bugs item #617110, was opened at 2002-10-01 18:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Nobody/Anonymous (nobody) Summary: SIGINT handler no longer installable. Initial Comment: After the following commands: >>> import signal >>> signal.signal(signal.SIGINT,signal.SIG_IGN) >>> print signal.getsignal(signal.SIGINT) 1 >>> Typing control-C or sending the process a SIGINT leads to a KeyboardInterrupt exception. Installing a signal handler instead of SIG_IGN doesn't help. The docs clearly state that the default handler can be overridden. Also in python 1.5.2 the above example works as I would expect - both control-C and SIGINT are ignored in that version. I'm running 2.2.1 on Solaris. I have seen the problem under Linux also. Python 2.2.1 (#1, Jul 16 2002, 15:22:16) [GCC 2.95.2 19991024 (release)] on sunos5 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 16:19 Message: Logged In: YES user_id=21627 Can you demonstrate the problem in a self-contained script, instead of an interactive session? If not, it is likely a readline issue - not one that we can do much about, so we would then close this report as "Won't fix". ---------------------------------------------------------------------- Comment By: Thorstein Thorsteinsson (thorstein) Date: 2002-10-02 15:05 Message: Logged In: YES user_id=587322 readline: That seems likely actually. I'm using readline both on the above installation and on the Linux installation referred to. A slightly earlier install without readline works ok: Python 2.1.1 (#3, Nov 29 2001, 17:41:42) [GCC 2.95.2 19991024 (release)] on sunos5 Also, if the Python process isn't connected to a terminal things work fine. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 14:32 Message: Logged In: YES user_id=6656 I find this sort of thing is usually readline's fault. Is that possible here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 From noreply@sourceforge.net Wed Oct 2 15:42:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 07:42:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-617110 ] SIGINT handler no longer installable. Message-ID: Bugs item #617110, was opened at 2002-10-01 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Nobody/Anonymous (nobody) Summary: SIGINT handler no longer installable. Initial Comment: After the following commands: >>> import signal >>> signal.signal(signal.SIGINT,signal.SIG_IGN) >>> print signal.getsignal(signal.SIGINT) 1 >>> Typing control-C or sending the process a SIGINT leads to a KeyboardInterrupt exception. Installing a signal handler instead of SIG_IGN doesn't help. The docs clearly state that the default handler can be overridden. Also in python 1.5.2 the above example works as I would expect - both control-C and SIGINT are ignored in that version. I'm running 2.2.1 on Solaris. I have seen the problem under Linux also. Python 2.2.1 (#1, Jul 16 2002, 15:22:16) [GCC 2.95.2 19991024 (release)] on sunos5 ---------------------------------------------------------------------- >Comment By: Thorstein Thorsteinsson (thorstein) Date: 2002-10-02 14:42 Message: Logged In: YES user_id=587322 self-contained script: No, the problem *only* occurs interactively and with readline. So closing the report seems reasonable to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 14:19 Message: Logged In: YES user_id=21627 Can you demonstrate the problem in a self-contained script, instead of an interactive session? If not, it is likely a readline issue - not one that we can do much about, so we would then close this report as "Won't fix". ---------------------------------------------------------------------- Comment By: Thorstein Thorsteinsson (thorstein) Date: 2002-10-02 13:05 Message: Logged In: YES user_id=587322 readline: That seems likely actually. I'm using readline both on the above installation and on the Linux installation referred to. A slightly earlier install without readline works ok: Python 2.1.1 (#3, Nov 29 2001, 17:41:42) [GCC 2.95.2 19991024 (release)] on sunos5 Also, if the Python process isn't connected to a terminal things work fine. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 12:32 Message: Logged In: YES user_id=6656 I find this sort of thing is usually readline's fault. Is that possible here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 From noreply@sourceforge.net Wed Oct 2 17:17:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 09:17:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-617110 ] SIGINT handler no longer installable. Message-ID: Bugs item #617110, was opened at 2002-10-01 18:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Nobody/Anonymous (nobody) Summary: SIGINT handler no longer installable. Initial Comment: After the following commands: >>> import signal >>> signal.signal(signal.SIGINT,signal.SIG_IGN) >>> print signal.getsignal(signal.SIGINT) 1 >>> Typing control-C or sending the process a SIGINT leads to a KeyboardInterrupt exception. Installing a signal handler instead of SIG_IGN doesn't help. The docs clearly state that the default handler can be overridden. Also in python 1.5.2 the above example works as I would expect - both control-C and SIGINT are ignored in that version. I'm running 2.2.1 on Solaris. I have seen the problem under Linux also. Python 2.2.1 (#1, Jul 16 2002, 15:22:16) [GCC 2.95.2 19991024 (release)] on sunos5 ---------------------------------------------------------------------- Comment By: Thorstein Thorsteinsson (thorstein) Date: 2002-10-02 16:42 Message: Logged In: YES user_id=587322 self-contained script: No, the problem *only* occurs interactively and with readline. So closing the report seems reasonable to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 16:19 Message: Logged In: YES user_id=21627 Can you demonstrate the problem in a self-contained script, instead of an interactive session? If not, it is likely a readline issue - not one that we can do much about, so we would then close this report as "Won't fix". ---------------------------------------------------------------------- Comment By: Thorstein Thorsteinsson (thorstein) Date: 2002-10-02 15:05 Message: Logged In: YES user_id=587322 readline: That seems likely actually. I'm using readline both on the above installation and on the Linux installation referred to. A slightly earlier install without readline works ok: Python 2.1.1 (#3, Nov 29 2001, 17:41:42) [GCC 2.95.2 19991024 (release)] on sunos5 Also, if the Python process isn't connected to a terminal things work fine. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-02 14:32 Message: Logged In: YES user_id=6656 I find this sort of thing is usually readline's fault. Is that possible here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617110&group_id=5470 From noreply@sourceforge.net Wed Oct 2 21:44:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 13:44:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-616786 ] Problems (fixes) compiling 2.2.1 on sun4 Message-ID: Bugs item #616786, was opened at 2002-09-30 17:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616786&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: Problems (fixes) compiling 2.2.1 on sun4 Initial Comment: I had a few problems compiling "Python-2.2.1" on "SunOS 4.1.4 1 sun4m" using gcc "version egcs-2.91.5" (sorry it's not my system and I had no choice). I'd guess this applies to other versions of python as well, but this is the first time I tried this. The most serious problem was in the function "PyOS_vsnprintf" in the file "Python/mysnprintf.c". For the case where HAVE_SNPRINTF is NOT #defined there is the call, len = vsprintf(buffer, format, va); But on "SunOS 4.1.4", on success "vsprintf" returns the first argument (buffer) and NOT the length of the string! I "fixed" this by adding after the above call, if (len == (int)buffer) len = strlen(buffer); I guess a better way would be to have a #ifdef for the OS but this seems to work OK for all systems. Three other source files needed minor tweaking: -- In Objects/fileobject.c at the beginning of function file_init() I needed to add the line: extern int fclose(FILE *); -- In Modules/posixmodule.c at the beginning of function posix_chroot() I needed to add the line: int chroot(); -- In Modules/xxsubtype.c at the beginning of function spam_bench() I needed to add the lines: #ifndef CLOCKS_PER_SEC # define CLOCKS_PER_SEC 1000000l /* ? */ #endif Seems like the first 2 would be OK in general. And perhaps there's an equivalent of CLOCKS_PER_SEC in some "sun4" header file but I couldn't find it. I realize supporting this antiquated operation system and "gcc" isn't a high priority, but since the changes are so minimal perhaps they could be added to save some other poor soul some headaches. ---------------------------------------------------------------------- >Comment By: No Spam (not4spam) Date: 2002-10-02 16:44 Message: Logged In: YES user_id=620948 I guess forget it then. I did't realize suport for SunOS 4 was being discontinued, but I can't blame you. I'll try to get my ISP (eskimo.com) to upgrade to something more modern and hopefully I can use this to help pursuade them. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 10:17 Message: Logged In: YES user_id=21627 According to PEP 11 (http://www.python.org/peps/pep-0011.html) SunOS 4 will become unsupported in Python 2.3, and the remaining pieces will be removed in Python 2.4. If you volunteer to support the SunOS port, we can re-support it, you can then submit patches for both 2.2 and 2.3. Without a volunteer who actively maintains the port, we will have to close this report as "Won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616786&group_id=5470 From noreply@sourceforge.net Thu Oct 3 03:06:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 19:06:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-617870 ] fcntl.flock() doesn't work in solaris Message-ID: Bugs item #617870, was opened at 2002-10-02 21:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617870&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: João Prado Maia (jcpm) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.flock() doesn't work in solaris Initial Comment: When trying the script below on Solaris: # test_flock.py import fcntl def lock(fd, flags): fcntl.flock(fd.fileno(), flags) def unlock(fd): fcntl.flock(fd.fileno(), fcntl.LOCK_UN) fd = open('test.txt', 'w') lock(fd, fcntl.LOCK_SH) fd.write('testing') unlock(fd) fd.close() # end of test_flock.py $ uname -a SunOS mercury 5.8 Generic_108529-13 i86pc i386 i86pc I get the following output: $ python test_flock.py Traceback (most recent call last): File "test_flock.py", line 10, in ? lock(fd, fcntl.LOCK_SH) File "test_flock.py", line 4, in lock fcntl.flock(fd.fileno(), flags) IOError: [Errno 9] Bad file number This is the python version information: $ python -V Python 2.2.1 However, when I try the same script under Linux it works correctly (i.e. it creates the 'test.txt' file) $ uname -a Linux domain.com 2.4.9-31 #1 Tue Feb 26 07:11:02 EST 2002 i686 unknown Please let me know if you need any more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617870&group_id=5470 From noreply@sourceforge.net Thu Oct 3 03:33:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 19:33:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-617878 ] parse error compiling on Solaris Message-ID: Bugs item #617878, was opened at 2002-10-02 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617878&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: parse error compiling on Solaris Initial Comment: Attempting to compile current CVS version on Solaris 2.6 generates a parse error: In file included from Python/thread_pthread.h:9, from Python/thread.c:104: /usr/include/pthread.h:159: parse error before `destructor' /usr/include/pthread.h:159: parse error before `)' make: *** [Python/thread.o] Error 1 $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617878&group_id=5470 From noreply@sourceforge.net Thu Oct 3 07:08:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 23:08:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-616211 ] packages doc in the tutorial Message-ID: Bugs item #616211, was opened at 2002-09-29 13:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616211&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: packages doc in the tutorial Initial Comment: The packages section in the tutorial (6.4) could be more explicit about the fact that top-level packages are supposed to be direct subdirs of dirs on sys.path. It seems that is this not stated explicitly. The section seems to come straight from the packages' essay, which in the whole made that clear. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-03 01:08 Message: Logged In: YES user_id=80475 Draft patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616211&group_id=5470 From noreply@sourceforge.net Thu Oct 3 07:51:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 02 Oct 2002 23:51:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-616716 ] Bug in PyErr_SetExcFromWindows...? Message-ID: Bugs item #616716, was opened at 2002-10-01 05:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616716&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Mark Hammond (mhammond) Summary: Bug in PyErr_SetExcFromWindows...? Initial Comment: On Win98SE I was running ZEO tests (a Zope thing) in a loop for hours, under current CVS. It eventually blew up with a memory fault. select() returned SOCKET_ERROR, and then WSAGetLastError() returned WSAEINTR. That's all normal here. Python calls PyErr_SetExcFromWindowsErr(SelectError, WSAGetLastError()); and WSAEINTR==10004 is the second argument. This *eventually* blew up in MS's strlen() function, reached via a long chain of calls starting at PyErr_SetExcFromWindowsErrWithFilename's v = Py_BuildValue("(is)", err, s); The problem is here: s makes no sense. It's a tiny integer (0x2714), not a legit char*. In fact, 0x2714 == 10004, the error code passed in! Now the local vrbl len is 0 at this point, and len is the return value from FormatMessage(). To my eyes, this means FormatMessage() failed, but the code doesn't appear to check for failure from that function. If FormatMessage() does fail, I don't see a guarantee in the MS docs that &s will get a sensible value stored into it, in which case the value of s is just stack trash (and it's quite plausible that 10004 is sitting on the stack at this point). Make sense? Looks to me like we have to check for failure in FormatMessage. Unfortunately, I have no idea why this call would fail. It's plausible that running ZEO tests in a loop for hours causes Win98SE to run out of some sort of internal resource, and I've never been able to run ZEO tests for hours on any flavor of Windows before. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-03 16:51 Message: Logged In: YES user_id=14198 I agree it is probably out of memory. Attaching a patch that still attempts to give something useful in this situation. If no objections I will check it in tomorrow (or sooner if someone agrees :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-01 05:54 Message: Logged In: YES user_id=6380 Maybe it's run out of memory? That's what usually kills ZEO tests on Linux in the end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616716&group_id=5470 From noreply@sourceforge.net Thu Oct 3 09:13:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 01:13:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-616786 ] Problems (fixes) compiling 2.2.1 on sun4 Message-ID: Bugs item #616786, was opened at 2002-09-30 23:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616786&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: No Spam (not4spam) Assigned to: Nobody/Anonymous (nobody) Summary: Problems (fixes) compiling 2.2.1 on sun4 Initial Comment: I had a few problems compiling "Python-2.2.1" on "SunOS 4.1.4 1 sun4m" using gcc "version egcs-2.91.5" (sorry it's not my system and I had no choice). I'd guess this applies to other versions of python as well, but this is the first time I tried this. The most serious problem was in the function "PyOS_vsnprintf" in the file "Python/mysnprintf.c". For the case where HAVE_SNPRINTF is NOT #defined there is the call, len = vsprintf(buffer, format, va); But on "SunOS 4.1.4", on success "vsprintf" returns the first argument (buffer) and NOT the length of the string! I "fixed" this by adding after the above call, if (len == (int)buffer) len = strlen(buffer); I guess a better way would be to have a #ifdef for the OS but this seems to work OK for all systems. Three other source files needed minor tweaking: -- In Objects/fileobject.c at the beginning of function file_init() I needed to add the line: extern int fclose(FILE *); -- In Modules/posixmodule.c at the beginning of function posix_chroot() I needed to add the line: int chroot(); -- In Modules/xxsubtype.c at the beginning of function spam_bench() I needed to add the lines: #ifndef CLOCKS_PER_SEC # define CLOCKS_PER_SEC 1000000l /* ? */ #endif Seems like the first 2 would be OK in general. And perhaps there's an equivalent of CLOCKS_PER_SEC in some "sun4" header file but I couldn't find it. I realize supporting this antiquated operation system and "gcc" isn't a high priority, but since the changes are so minimal perhaps they could be added to save some other poor soul some headaches. ---------------------------------------------------------------------- Comment By: No Spam (not4spam) Date: 2002-10-02 22:44 Message: Logged In: YES user_id=620948 I guess forget it then. I did't realize suport for SunOS 4 was being discontinued, but I can't blame you. I'll try to get my ISP (eskimo.com) to upgrade to something more modern and hopefully I can use this to help pursuade them. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-02 16:17 Message: Logged In: YES user_id=21627 According to PEP 11 (http://www.python.org/peps/pep-0011.html) SunOS 4 will become unsupported in Python 2.3, and the remaining pieces will be removed in Python 2.4. If you volunteer to support the SunOS port, we can re-support it, you can then submit patches for both 2.2 and 2.3. Without a volunteer who actively maintains the port, we will have to close this report as "Won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616786&group_id=5470 From noreply@sourceforge.net Thu Oct 3 09:21:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 01:21:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-617878 ] parse error compiling on Solaris Message-ID: Bugs item #617878, was opened at 2002-10-03 04:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617878&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: parse error compiling on Solaris Initial Comment: Attempting to compile current CVS version on Solaris 2.6 generates a parse error: In file included from Python/thread_pthread.h:9, from Python/thread.c:104: /usr/include/pthread.h:159: parse error before `destructor' /usr/include/pthread.h:159: parse error before `)' make: *** [Python/thread.o] Error 1 $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:21 Message: Logged In: YES user_id=21627 That's a bug in the pthread headers of Solaris 2.6. You need to make the same change to thread_pthread.h that is done for APPLE. Would you like to design a patch to solve that problem? It would have to apply only to 2.6; later systems don't use destructor in the header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617878&group_id=5470 From noreply@sourceforge.net Thu Oct 3 09:36:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 01:36:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-617870 ] fcntl.flock() doesn't work in solaris Message-ID: Bugs item #617870, was opened at 2002-10-03 04:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617870&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: João Prado Maia (jcpm) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.flock() doesn't work in solaris Initial Comment: When trying the script below on Solaris: # test_flock.py import fcntl def lock(fd, flags): fcntl.flock(fd.fileno(), flags) def unlock(fd): fcntl.flock(fd.fileno(), fcntl.LOCK_UN) fd = open('test.txt', 'w') lock(fd, fcntl.LOCK_SH) fd.write('testing') unlock(fd) fd.close() # end of test_flock.py $ uname -a SunOS mercury 5.8 Generic_108529-13 i86pc i386 i86pc I get the following output: $ python test_flock.py Traceback (most recent call last): File "test_flock.py", line 10, in ? lock(fd, fcntl.LOCK_SH) File "test_flock.py", line 4, in lock fcntl.flock(fd.fileno(), flags) IOError: [Errno 9] Bad file number This is the python version information: $ python -V Python 2.2.1 However, when I try the same script under Linux it works correctly (i.e. it creates the 'test.txt' file) $ uname -a Linux domain.com 2.4.9-31 #1 Tue Feb 26 07:11:02 EST 2002 i686 unknown Please let me know if you need any more information. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:36 Message: Logged In: YES user_id=21627 This is not a bug in Python, but a feature of your system. >From flock(3UCB): Read permission is required on a file to obtain a shared lock, and write permission is required to obtain an exclusive lock. Since you haven't opened the file for reading, you can not obtain a shared lock - you need an exclusive lock for writing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617870&group_id=5470 From noreply@sourceforge.net Thu Oct 3 10:00:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 02:00:48 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 09:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Martin v. Löwis (loewis) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Thu Oct 3 10:38:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 02:38:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 19:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 15:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 09:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 16:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 09:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Thu Oct 3 11:08:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 03:08:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 19:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-03 10:08 Message: Logged In: YES user_id=6656 Here's a patch. Remarkably, it's just a one line patch to work around the SET_LINENO breakage. Other changes: * open the file for compiling in universal newlines mode. * always write the mtime to a .pyc little-endian-wise (2.2.2 candidate) * it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate) * bodge the parsermodule to return the encoding along with the encoding_decl non-terminal (this is pretty icky!) * let transformer cope with new 'testlist1' non-terminal * have transformer pick up the encoding declaration Still to do is using the encoding declaration to decode string literals. I think there should be an accessible from Python function to do this -- I really don't want to have to translate compile.c:parsestr into Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 15:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 09:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 16:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 09:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Thu Oct 3 11:44:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 03:44:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-618012 ] plat-linux2/IN.py FutureWarning's Message-ID: Bugs item #618012, was opened at 2002-10-03 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618012&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: plat-linux2/IN.py FutureWarning's Initial Comment: Between lines 182 and 205 the warning is triggered a few times, i.e.: IN.py:184: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up IN_CLASSA_NET = 0xff000000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618012&group_id=5470 From noreply@sourceforge.net Thu Oct 3 12:18:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 04:18:57 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-618023 ] imap handler in urllib(2) Message-ID: Feature Requests item #618023, was opened at 2002-10-03 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618023&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Asle Pedersen (apederse) Assigned to: Nobody/Anonymous (nobody) Summary: imap handler in urllib(2) Initial Comment: There should be an imap handler in urllib/urllib2. RFC 2192 defines the behaviour. I have made a first attempt at this using code from ftp_open and ftp_wrapper in order to cache imap connections and it seem to work ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618023&group_id=5470 From noreply@sourceforge.net Thu Oct 3 12:20:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 04:20:54 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-618024 ] urlparse fails on imap:// Message-ID: Feature Requests item #618024, was opened at 2002-10-03 11:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Asle Pedersen (apederse) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse fails on imap:// Initial Comment: urlparse does not parse imap:// urls (RFC 2192). I am not all sure but this seem to be an appropriate patch: urlparse.uses_relative.append('imap') urlparse.uses_netloc.append('imap') urlparse.non_hierarchical.append('imap') urlparse.uses_params.append('imap') urlparse.uses_query.append('imap') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 From noreply@sourceforge.net Thu Oct 3 15:44:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 07:44:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-618095 ] posixmodule.c fails on Solaris 2.6 Message-ID: Bugs item #618095, was opened at 2002-10-03 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618095&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule.c fails on Solaris 2.6 Initial Comment: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include \ -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o In file included from /usr/include/sys/wait.h:24, from /usr/include/stdlib.h:22, from Include/Python.h:36, from ./Modules/posixmodule.c:16: /usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside parameter list /usr/include/sys/resource.h:148: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside parameter list ./Modules/posixmodule.c: In function `posix_utime': ./Modules/posixmodule.c:1493: warning: implicit declaration of function `utimes' In file included from ./Modules/posixmodule.c:5117: /usr/include/sys/statvfs.h: At top level: /usr/include/sys/statvfs.h:93: warning: `struct statvfs64' declared inside parameter list /usr/include/sys/statvfs.h:94: warning: `struct statvfs64' declared inside parameter list ./Modules/posixmodule.c:5120: warning: `struct statvfs64' declared inside parameter list ./Modules/posixmodule.c:5120: parameter `st' has incomplete type ./Modules/posixmodule.c: In function `posix_fstatvfs': ./Modules/posixmodule.c:5166: storage size of `st' isn't known ./Modules/posixmodule.c:5176: type of formal parameter 1 is incomplete ./Modules/posixmodule.c:5166: warning: unused variable `st' ./Modules/posixmodule.c: In function `posix_statvfs': ./Modules/posixmodule.c:5193: storage size of `st' isn't known ./Modules/posixmodule.c:5202: type of formal parameter 1 is incomplete ./Modules/posixmodule.c:5193: warning: unused variable `st' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618095&group_id=5470 From noreply@sourceforge.net Thu Oct 3 16:24:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 08:24:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-616324 ] unittest.main broken Message-ID: Bugs item #616324, was opened at 2002-09-29 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616324&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Williams (johnw42) Assigned to: Nobody/Anonymous (nobody) Summary: unittest.main broken Initial Comment: The unittest.main function is broken in CVS. In version 2.2, running "python break_unittest.py" runs test test case correctly, but the current version acts as if there are no test cases defined. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-03 15:24 Message: Logged In: YES user_id=31392 Guido checked in a fix for this a couple of days ago. When unittest changed its default metaclass to type, it should have also changed the test it used for whether a TestCase was a class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616324&group_id=5470 From noreply@sourceforge.net Thu Oct 3 16:58:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 08:58:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-616716 ] Bug in PyErr_SetExcFromWindows...? Message-ID: Bugs item #616716, was opened at 2002-09-30 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616716&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Mark Hammond (mhammond) Summary: Bug in PyErr_SetExcFromWindows...? Initial Comment: On Win98SE I was running ZEO tests (a Zope thing) in a loop for hours, under current CVS. It eventually blew up with a memory fault. select() returned SOCKET_ERROR, and then WSAGetLastError() returned WSAEINTR. That's all normal here. Python calls PyErr_SetExcFromWindowsErr(SelectError, WSAGetLastError()); and WSAEINTR==10004 is the second argument. This *eventually* blew up in MS's strlen() function, reached via a long chain of calls starting at PyErr_SetExcFromWindowsErrWithFilename's v = Py_BuildValue("(is)", err, s); The problem is here: s makes no sense. It's a tiny integer (0x2714), not a legit char*. In fact, 0x2714 == 10004, the error code passed in! Now the local vrbl len is 0 at this point, and len is the return value from FormatMessage(). To my eyes, this means FormatMessage() failed, but the code doesn't appear to check for failure from that function. If FormatMessage() does fail, I don't see a guarantee in the MS docs that &s will get a sensible value stored into it, in which case the value of s is just stack trash (and it's quite plausible that 10004 is sitting on the stack at this point). Make sense? Looks to me like we have to check for failure in FormatMessage. Unfortunately, I have no idea why this call would fail. It's plausible that running ZEO tests in a loop for hours causes Win98SE to run out of some sort of internal resource, and I've never been able to run ZEO tests for hours on any flavor of Windows before. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-03 11:58 Message: Logged In: YES user_id=31435 Go for it, Mark! Looks fine to me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 02:51 Message: Logged In: YES user_id=14198 I agree it is probably out of memory. Attaching a patch that still attempts to give something useful in this situation. If no objections I will check it in tomorrow (or sooner if someone agrees :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-30 15:54 Message: Logged In: YES user_id=6380 Maybe it's run out of memory? That's what usually kills ZEO tests on Linux in the end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616716&group_id=5470 From noreply@sourceforge.net Thu Oct 3 17:35:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 09:35:35 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) >Assigned to: Nobody/Anonymous (nobody) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 18:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Thu Oct 3 17:45:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 09:45:45 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 09:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-03 16:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 16:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Thu Oct 3 17:57:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 09:57:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-618146 ] overflow error in calendar module Message-ID: Bugs item #618146, was opened at 2002-10-03 16:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 Category: None Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kaleb Pederson (kibab) Assigned to: Nobody/Anonymous (nobody) Summary: overflow error in calendar module Initial Comment: The calendar module doesn't explicitly say that it doesn't work for dates pre-1970. The best case is that this is a DOCUMENTATION BUG. I would prefer to see a more powerful date module that starts at the beginning of the Gregorian calendar. What it does say: >From http://www.python.org/doc/current/lib/module- calendar.html: (when 2.2.1 is current) weekday(year, month, day) - Returns the day of the week (0 is Monday) for year (1970-...), month (1-12), day (1-31). // I figured that was fine, I can avoid using that function in my wrapper timegm(tuple) - An unrelated but handy function that takes a time tuple such as returned by the gmtime() function in the time module, and returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others' inverse. // Okay, I can avoid that too, especially since it is "unrelated" I probably should have got a clue based on the above, but I didn't.... Here is the traceback: (under python 2.2.1-Windows) >>> import calendar >>> calendar.monthcalendar(1969,12) Traceback (most recent call last): File "", line 1, in ? File "c:\progra~1\python22\lib\calendar.py", line 122, in monthcalendar day1, ndays = monthrange(year, month) File "c:\progra~1\python22\lib\calendar.py", line 115, in monthrange day1 = weekday(year, month, 1) File "c:\progra~1\python22\lib\calendar.py", line 106, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range The error is identical under Linux There was one related "bug report" previously but nothing else identical: [ 434143 ] calendar module broken for 1900 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618146&group_id=5470 From noreply@sourceforge.net Thu Oct 3 18:55:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 10:55:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 19:55 Message: Logged In: YES user_id=21627 I see. For a different reason (interactive mode), I have been contemplating to recognize a variable source_encoding in globals(), which would be set in interactive mode to the terminal's encoding, so that input of non-ASCII Unicode literals would "work", without having to type an encoding declaration each time. I believe such a mechanism could also solve this problem; callers of eval would have to set the global. What do you think? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 18:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 18:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Thu Oct 3 19:11:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 11:11:36 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 09:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-03 18:11 Message: Logged In: YES user_id=38388 I believe the correct way to handle this would be to have eval() accept Unicode and then convert it to UTF-8 for the parser to process. The PEP only talks about compile() which should accept Unicode objects, but eval() is certainly a candidate too. About the source_encoding idea: wouldn't it be better to define this for interactive use in the sys module ? A Python startup script could then be used to set this variable in interactive mode. BTW, it's better to discuss these things on python-dev than in these small textareas... IMHO, at least. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:55 Message: Logged In: YES user_id=21627 I see. For a different reason (interactive mode), I have been contemplating to recognize a variable source_encoding in globals(), which would be set in interactive mode to the terminal's encoding, so that input of non-ASCII Unicode literals would "work", without having to type an encoding declaration each time. I believe such a mechanism could also solve this problem; callers of eval would have to set the global. What do you think? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 16:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 16:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Thu Oct 3 20:21:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 12:21:40 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 11:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 21:21 Message: Logged In: YES user_id=21627 That would not be correct. If you have a (plain) string literal, it would end up encoded as UTF-8, whereas the original source encoding was, say, Latin-1. People will be confused if string literals don't come out in the expected encoding in interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-03 20:11 Message: Logged In: YES user_id=38388 I believe the correct way to handle this would be to have eval() accept Unicode and then convert it to UTF-8 for the parser to process. The PEP only talks about compile() which should accept Unicode objects, but eval() is certainly a candidate too. About the source_encoding idea: wouldn't it be better to define this for interactive use in the sys module ? A Python startup script could then be used to set this variable in interactive mode. BTW, it's better to discuss these things on python-dev than in these small textareas... IMHO, at least. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 19:55 Message: Logged In: YES user_id=21627 I see. For a different reason (interactive mode), I have been contemplating to recognize a variable source_encoding in globals(), which would be set in interactive mode to the terminal's encoding, so that input of non-ASCII Unicode literals would "work", without having to type an encoding declaration each time. I believe such a mechanism could also solve this problem; callers of eval would have to set the global. What do you think? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 18:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 18:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Fri Oct 4 01:13:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 17:13:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-616716 ] Bug in PyErr_SetExcFromWindows...? Message-ID: Bugs item #616716, was opened at 2002-10-01 05:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616716&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Mark Hammond (mhammond) Summary: Bug in PyErr_SetExcFromWindows...? Initial Comment: On Win98SE I was running ZEO tests (a Zope thing) in a loop for hours, under current CVS. It eventually blew up with a memory fault. select() returned SOCKET_ERROR, and then WSAGetLastError() returned WSAEINTR. That's all normal here. Python calls PyErr_SetExcFromWindowsErr(SelectError, WSAGetLastError()); and WSAEINTR==10004 is the second argument. This *eventually* blew up in MS's strlen() function, reached via a long chain of calls starting at PyErr_SetExcFromWindowsErrWithFilename's v = Py_BuildValue("(is)", err, s); The problem is here: s makes no sense. It's a tiny integer (0x2714), not a legit char*. In fact, 0x2714 == 10004, the error code passed in! Now the local vrbl len is 0 at this point, and len is the return value from FormatMessage(). To my eyes, this means FormatMessage() failed, but the code doesn't appear to check for failure from that function. If FormatMessage() does fail, I don't see a guarantee in the MS docs that &s will get a sensible value stored into it, in which case the value of s is just stack trash (and it's quite plausible that 10004 is sitting on the stack at this point). Make sense? Looks to me like we have to check for failure in FormatMessage. Unfortunately, I have no idea why this call would fail. It's plausible that running ZEO tests in a loop for hours causes Win98SE to run out of some sort of internal resource, and I've never been able to run ZEO tests for hours on any flavor of Windows before. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-10-04 10:13 Message: Logged In: YES user_id=14198 Checking in errors.c; /cvsroot/python/python/dist/src/Python/errors.c,v <-- errors.c new revision: 2.74; previous revision: 2.73 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-04 01:58 Message: Logged In: YES user_id=31435 Go for it, Mark! Looks fine to me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-10-03 16:51 Message: Logged In: YES user_id=14198 I agree it is probably out of memory. Attaching a patch that still attempts to give something useful in this situation. If no objections I will check it in tomorrow (or sooner if someone agrees :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-01 05:54 Message: Logged In: YES user_id=6380 Maybe it's run out of memory? That's what usually kills ZEO tests on Linux in the end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616716&group_id=5470 From noreply@sourceforge.net Fri Oct 4 07:36:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 03 Oct 2002 23:36:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-616002 ] getdefaultlocale failure on OS X Message-ID: Bugs item #616002, was opened at 2002-09-29 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: getdefaultlocale failure on OS X Initial Comment: My OS X laptop did not have LANG set in the bash envrionment and idle (AquaTK) failed to launch with an AttributeError in IOBinding.py try: encoding = locale.getdefaultlocale()[1] codecs.lookup(encoding) except (ValueError, LookupError): pass encoding = encoding.lower() ^^^^^ encoding is None here because locale.getdefaultlocale() returns (None, None) when the locale can't be determined. After finding that adding LANG=en_US to my .bashrc didn't help, I Iearned OS X GUI apps don't use the shell's environment, but do use whatever they find in ~/.MacOSX/environment.plist. Adding a couple lines: LANG en_US makes idle happy. An alternative would be to make sure encoding never gets set to None. --- IOBinding.py.orig Sat Sep 28 17:17:02 2002 +++ IOBinding.py Sat Sep 28 17:17:42 2002 @@ -64,7 +64,7 @@ # which may give a clue. Unfortunately, getdefaultlocale has # bugs that can cause ValueError. try: - encoding = locale.getdefaultlocale()[1] + encoding = locale.getdefaultlocale()[1] or 'ascii' codecs.lookup(encoding) except (ValueError, LookupError): pass ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2002-10-04 06:36 Message: Logged In: YES user_id=17671 This may as well be closed. I see in the latest Python-dev summary that Guido asked for all future changes to be done in the idle-fork project. Tony Lownds checked in a work-around to the idle-fork project on 09/23 which is similar to what I was suggesting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 08:46 Message: Logged In: YES user_id=21627 Feel free to use any work-around you feel comfortable with. However, I won't approve a fix that I know is wrong. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 08:35 Message: Logged In: YES user_id=17671 I was surprised falling back to ascii actually worked. I found a bunch of docs at the devoper.apple.com site. As far as I can tell, the proper way to fix this is to add the necessary support to macglue.h, etc. so the functions in _locale work on OS X as well. I found out why this only just now bit me: I had compatible libs in /usr/local/lib which made nl_langinfo() available in _locale until I upgraded to 10.2.1. The proper fix is going to require some effort by someone who understands Apple API's much better than I do. Since falling back to ascii works (at least for en_US) as you intended - you were the one who added the locale code to IOBinding.py - perhaps a temporary fix is to make sure the fallback works as you intended? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 07:38 Message: Logged In: YES user_id=21627 I agree that there is a bug somewhere. I also suspect that the bug is in IDLE, but I think it is wrong to fall-back to ASCII on OS X (I'm almost certain that the user's encoding is never just ASCII on that system). I suspect that it is MacRoman or some such, but I also suspect that this either might vary with the localized version of OS X (assuming there are localized versions), or with a per-user setting. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 02:18 Message: Logged In: YES user_id=17671 I've done a little digging and have yet to find a satisfactory answer. This article: http://developer.apple.com/internet/macosx/perl.html has instructions for upgrading perl to 5.8.0 "OS X has one of the necessary environment variables set (LANG), but without the above, you'll get annoying error messages each time you try to run a script. The above assumes the tcsh shell; if you prefer bash, use echo "export LC_ALL=C" >> ~/.bash_profile instead." I'll keep digging for a good answer, but I still believe there is a bug here. If you look in IOBinding.py, you'll see that encoding is given a default value of "ascii". It should leave the section with that value intact or with ascii replaced with the proper locale. The possibility that getdefaultlocale will punt and return (None, None) is not taken into account in IOBinding.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-29 22:17 Message: Logged In: YES user_id=21627 Can you please find out how to determine the user's prefererred encoding on OS X? Yes, getdefaultlocale is broken, but that is by design, and cannot be fixed. So we should reduce its usage instead of trying to correct it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 From noreply@sourceforge.net Fri Oct 4 08:28:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 00:28:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-616002 ] getdefaultlocale failure on OS X Message-ID: Bugs item #616002, was opened at 2002-09-29 02:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: getdefaultlocale failure on OS X Initial Comment: My OS X laptop did not have LANG set in the bash envrionment and idle (AquaTK) failed to launch with an AttributeError in IOBinding.py try: encoding = locale.getdefaultlocale()[1] codecs.lookup(encoding) except (ValueError, LookupError): pass encoding = encoding.lower() ^^^^^ encoding is None here because locale.getdefaultlocale() returns (None, None) when the locale can't be determined. After finding that adding LANG=en_US to my .bashrc didn't help, I Iearned OS X GUI apps don't use the shell's environment, but do use whatever they find in ~/.MacOSX/environment.plist. Adding a couple lines: LANG en_US makes idle happy. An alternative would be to make sure encoding never gets set to None. --- IOBinding.py.orig Sat Sep 28 17:17:02 2002 +++ IOBinding.py Sat Sep 28 17:17:42 2002 @@ -64,7 +64,7 @@ # which may give a clue. Unfortunately, getdefaultlocale has # bugs that can cause ValueError. try: - encoding = locale.getdefaultlocale()[1] + encoding = locale.getdefaultlocale()[1] or 'ascii' codecs.lookup(encoding) except (ValueError, LookupError): pass ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 09:28 Message: Logged In: YES user_id=21627 You can probably guess that I dislike the change being done to IDLE. Oh well. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-04 08:36 Message: Logged In: YES user_id=17671 This may as well be closed. I see in the latest Python-dev summary that Guido asked for all future changes to be done in the idle-fork project. Tony Lownds checked in a work-around to the idle-fork project on 09/23 which is similar to what I was suggesting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 10:46 Message: Logged In: YES user_id=21627 Feel free to use any work-around you feel comfortable with. However, I won't approve a fix that I know is wrong. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 10:35 Message: Logged In: YES user_id=17671 I was surprised falling back to ascii actually worked. I found a bunch of docs at the devoper.apple.com site. As far as I can tell, the proper way to fix this is to add the necessary support to macglue.h, etc. so the functions in _locale work on OS X as well. I found out why this only just now bit me: I had compatible libs in /usr/local/lib which made nl_langinfo() available in _locale until I upgraded to 10.2.1. The proper fix is going to require some effort by someone who understands Apple API's much better than I do. Since falling back to ascii works (at least for en_US) as you intended - you were the one who added the locale code to IOBinding.py - perhaps a temporary fix is to make sure the fallback works as you intended? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 09:38 Message: Logged In: YES user_id=21627 I agree that there is a bug somewhere. I also suspect that the bug is in IDLE, but I think it is wrong to fall-back to ASCII on OS X (I'm almost certain that the user's encoding is never just ASCII on that system). I suspect that it is MacRoman or some such, but I also suspect that this either might vary with the localized version of OS X (assuming there are localized versions), or with a per-user setting. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 04:18 Message: Logged In: YES user_id=17671 I've done a little digging and have yet to find a satisfactory answer. This article: http://developer.apple.com/internet/macosx/perl.html has instructions for upgrading perl to 5.8.0 "OS X has one of the necessary environment variables set (LANG), but without the above, you'll get annoying error messages each time you try to run a script. The above assumes the tcsh shell; if you prefer bash, use echo "export LC_ALL=C" >> ~/.bash_profile instead." I'll keep digging for a good answer, but I still believe there is a bug here. If you look in IOBinding.py, you'll see that encoding is given a default value of "ascii". It should leave the section with that value intact or with ascii replaced with the proper locale. The possibility that getdefaultlocale will punt and return (None, None) is not taken into account in IOBinding.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 00:17 Message: Logged In: YES user_id=21627 Can you please find out how to determine the user's prefererred encoding on OS X? Yes, getdefaultlocale is broken, but that is by design, and cannot be fixed. So we should reduce its usage instead of trying to correct it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 From noreply@sourceforge.net Fri Oct 4 08:53:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 00:53:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-616002 ] getdefaultlocale failure on OS X Message-ID: Bugs item #616002, was opened at 2002-09-29 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: getdefaultlocale failure on OS X Initial Comment: My OS X laptop did not have LANG set in the bash envrionment and idle (AquaTK) failed to launch with an AttributeError in IOBinding.py try: encoding = locale.getdefaultlocale()[1] codecs.lookup(encoding) except (ValueError, LookupError): pass encoding = encoding.lower() ^^^^^ encoding is None here because locale.getdefaultlocale() returns (None, None) when the locale can't be determined. After finding that adding LANG=en_US to my .bashrc didn't help, I Iearned OS X GUI apps don't use the shell's environment, but do use whatever they find in ~/.MacOSX/environment.plist. Adding a couple lines: LANG en_US makes idle happy. An alternative would be to make sure encoding never gets set to None. --- IOBinding.py.orig Sat Sep 28 17:17:02 2002 +++ IOBinding.py Sat Sep 28 17:17:42 2002 @@ -64,7 +64,7 @@ # which may give a clue. Unfortunately, getdefaultlocale has # bugs that can cause ValueError. try: - encoding = locale.getdefaultlocale()[1] + encoding = locale.getdefaultlocale()[1] or 'ascii' codecs.lookup(encoding) except (ValueError, LookupError): pass ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2002-10-04 07:53 Message: Logged In: YES user_id=17671 I apologize it this comment reopens this bug. Inititially, I had a hard time understanding your objection, given that my suggestion would have merely made the code behave as you had intended when you wrote it. Upon reflection, however, I understand why you are objecting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 07:28 Message: Logged In: YES user_id=21627 You can probably guess that I dislike the change being done to IDLE. Oh well. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-04 06:36 Message: Logged In: YES user_id=17671 This may as well be closed. I see in the latest Python-dev summary that Guido asked for all future changes to be done in the idle-fork project. Tony Lownds checked in a work-around to the idle-fork project on 09/23 which is similar to what I was suggesting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 08:46 Message: Logged In: YES user_id=21627 Feel free to use any work-around you feel comfortable with. However, I won't approve a fix that I know is wrong. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 08:35 Message: Logged In: YES user_id=17671 I was surprised falling back to ascii actually worked. I found a bunch of docs at the devoper.apple.com site. As far as I can tell, the proper way to fix this is to add the necessary support to macglue.h, etc. so the functions in _locale work on OS X as well. I found out why this only just now bit me: I had compatible libs in /usr/local/lib which made nl_langinfo() available in _locale until I upgraded to 10.2.1. The proper fix is going to require some effort by someone who understands Apple API's much better than I do. Since falling back to ascii works (at least for en_US) as you intended - you were the one who added the locale code to IOBinding.py - perhaps a temporary fix is to make sure the fallback works as you intended? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 07:38 Message: Logged In: YES user_id=21627 I agree that there is a bug somewhere. I also suspect that the bug is in IDLE, but I think it is wrong to fall-back to ASCII on OS X (I'm almost certain that the user's encoding is never just ASCII on that system). I suspect that it is MacRoman or some such, but I also suspect that this either might vary with the localized version of OS X (assuming there are localized versions), or with a per-user setting. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 02:18 Message: Logged In: YES user_id=17671 I've done a little digging and have yet to find a satisfactory answer. This article: http://developer.apple.com/internet/macosx/perl.html has instructions for upgrading perl to 5.8.0 "OS X has one of the necessary environment variables set (LANG), but without the above, you'll get annoying error messages each time you try to run a script. The above assumes the tcsh shell; if you prefer bash, use echo "export LC_ALL=C" >> ~/.bash_profile instead." I'll keep digging for a good answer, but I still believe there is a bug here. If you look in IOBinding.py, you'll see that encoding is given a default value of "ascii". It should leave the section with that value intact or with ascii replaced with the proper locale. The possibility that getdefaultlocale will punt and return (None, None) is not taken into account in IOBinding.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-29 22:17 Message: Logged In: YES user_id=21627 Can you please find out how to determine the user's prefererred encoding on OS X? Yes, getdefaultlocale is broken, but that is by design, and cannot be fixed. So we should reduce its usage instead of trying to correct it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 From noreply@sourceforge.net Fri Oct 4 10:00:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 02:00:55 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 09:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-04 09:00 Message: Logged In: YES user_id=6656 MAL: I don't understand your first paragraph at all. The {sys.,}source_encoding variable might work, but it would be a dreadful hack for my purposes. Using eval() is already a nasty hack, IMHO. I agree a mailing list is a more civilised interface than a web browser... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 19:21 Message: Logged In: YES user_id=21627 That would not be correct. If you have a (plain) string literal, it would end up encoded as UTF-8, whereas the original source encoding was, say, Latin-1. People will be confused if string literals don't come out in the expected encoding in interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-03 18:11 Message: Logged In: YES user_id=38388 I believe the correct way to handle this would be to have eval() accept Unicode and then convert it to UTF-8 for the parser to process. The PEP only talks about compile() which should accept Unicode objects, but eval() is certainly a candidate too. About the source_encoding idea: wouldn't it be better to define this for interactive use in the sys module ? A Python startup script could then be used to set this variable in interactive mode. BTW, it's better to discuss these things on python-dev than in these small textareas... IMHO, at least. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:55 Message: Logged In: YES user_id=21627 I see. For a different reason (interactive mode), I have been contemplating to recognize a variable source_encoding in globals(), which would be set in interactive mode to the terminal's encoding, so that input of non-ASCII Unicode literals would "work", without having to type an encoding declaration each time. I believe such a mechanism could also solve this problem; callers of eval would have to set the global. What do you think? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 16:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 16:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Fri Oct 4 10:21:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 02:21:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-616002 ] getdefaultlocale failure on OS X Message-ID: Bugs item #616002, was opened at 2002-09-29 02:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: getdefaultlocale failure on OS X Initial Comment: My OS X laptop did not have LANG set in the bash envrionment and idle (AquaTK) failed to launch with an AttributeError in IOBinding.py try: encoding = locale.getdefaultlocale()[1] codecs.lookup(encoding) except (ValueError, LookupError): pass encoding = encoding.lower() ^^^^^ encoding is None here because locale.getdefaultlocale() returns (None, None) when the locale can't be determined. After finding that adding LANG=en_US to my .bashrc didn't help, I Iearned OS X GUI apps don't use the shell's environment, but do use whatever they find in ~/.MacOSX/environment.plist. Adding a couple lines: LANG en_US makes idle happy. An alternative would be to make sure encoding never gets set to None. --- IOBinding.py.orig Sat Sep 28 17:17:02 2002 +++ IOBinding.py Sat Sep 28 17:17:42 2002 @@ -64,7 +64,7 @@ # which may give a clue. Unfortunately, getdefaultlocale has # bugs that can cause ValueError. try: - encoding = locale.getdefaultlocale()[1] + encoding = locale.getdefaultlocale()[1] or 'ascii' codecs.lookup(encoding) except (ValueError, LookupError): pass ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 11:21 Message: Logged In: YES user_id=21627 I guess we can leave this closed until a MacOS expert comes along... To reiterate my opposition: I think it is wrong to use 'ascii' as the IDLE encoding on OS X. Even though OS X does support ascii, it supports more than that. As a result, people typing non-ASCII characters will find that IDLE cannot process them properly. This is unfortunate, as IDLE poses a restriction which no foundation in the system. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-04 09:53 Message: Logged In: YES user_id=17671 I apologize it this comment reopens this bug. Inititially, I had a hard time understanding your objection, given that my suggestion would have merely made the code behave as you had intended when you wrote it. Upon reflection, however, I understand why you are objecting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 09:28 Message: Logged In: YES user_id=21627 You can probably guess that I dislike the change being done to IDLE. Oh well. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-04 08:36 Message: Logged In: YES user_id=17671 This may as well be closed. I see in the latest Python-dev summary that Guido asked for all future changes to be done in the idle-fork project. Tony Lownds checked in a work-around to the idle-fork project on 09/23 which is similar to what I was suggesting. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 10:46 Message: Logged In: YES user_id=21627 Feel free to use any work-around you feel comfortable with. However, I won't approve a fix that I know is wrong. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 10:35 Message: Logged In: YES user_id=17671 I was surprised falling back to ascii actually worked. I found a bunch of docs at the devoper.apple.com site. As far as I can tell, the proper way to fix this is to add the necessary support to macglue.h, etc. so the functions in _locale work on OS X as well. I found out why this only just now bit me: I had compatible libs in /usr/local/lib which made nl_langinfo() available in _locale until I upgraded to 10.2.1. The proper fix is going to require some effort by someone who understands Apple API's much better than I do. Since falling back to ascii works (at least for en_US) as you intended - you were the one who added the locale code to IOBinding.py - perhaps a temporary fix is to make sure the fallback works as you intended? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 09:38 Message: Logged In: YES user_id=21627 I agree that there is a bug somewhere. I also suspect that the bug is in IDLE, but I think it is wrong to fall-back to ASCII on OS X (I'm almost certain that the user's encoding is never just ASCII on that system). I suspect that it is MacRoman or some such, but I also suspect that this either might vary with the localized version of OS X (assuming there are localized versions), or with a per-user setting. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-09-30 04:18 Message: Logged In: YES user_id=17671 I've done a little digging and have yet to find a satisfactory answer. This article: http://developer.apple.com/internet/macosx/perl.html has instructions for upgrading perl to 5.8.0 "OS X has one of the necessary environment variables set (LANG), but without the above, you'll get annoying error messages each time you try to run a script. The above assumes the tcsh shell; if you prefer bash, use echo "export LC_ALL=C" >> ~/.bash_profile instead." I'll keep digging for a good answer, but I still believe there is a bug here. If you look in IOBinding.py, you'll see that encoding is given a default value of "ascii". It should leave the section with that value intact or with ascii replaced with the proper locale. The possibility that getdefaultlocale will punt and return (None, None) is not taken into account in IOBinding.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 00:17 Message: Logged In: YES user_id=21627 Can you please find out how to determine the user's prefererred encoding on OS X? Yes, getdefaultlocale is broken, but that is by design, and cannot be fixed. So we should reduce its usage instead of trying to correct it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616002&group_id=5470 From noreply@sourceforge.net Fri Oct 4 11:23:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 03:23:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-618095 ] posixmodule.c fails on Solaris 2.6 Message-ID: Bugs item #618095, was opened at 2002-10-03 16:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618095&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule.c fails on Solaris 2.6 Initial Comment: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include \ -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o In file included from /usr/include/sys/wait.h:24, from /usr/include/stdlib.h:22, from Include/Python.h:36, from ./Modules/posixmodule.c:16: /usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside parameter list /usr/include/sys/resource.h:148: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside parameter list ./Modules/posixmodule.c: In function `posix_utime': ./Modules/posixmodule.c:1493: warning: implicit declaration of function `utimes' In file included from ./Modules/posixmodule.c:5117: /usr/include/sys/statvfs.h: At top level: /usr/include/sys/statvfs.h:93: warning: `struct statvfs64' declared inside parameter list /usr/include/sys/statvfs.h:94: warning: `struct statvfs64' declared inside parameter list ./Modules/posixmodule.c:5120: warning: `struct statvfs64' declared inside parameter list ./Modules/posixmodule.c:5120: parameter `st' has incomplete type ./Modules/posixmodule.c: In function `posix_fstatvfs': ./Modules/posixmodule.c:5166: storage size of `st' isn't known ./Modules/posixmodule.c:5176: type of formal parameter 1 is incomplete ./Modules/posixmodule.c:5166: warning: unused variable `st' ./Modules/posixmodule.c: In function `posix_statvfs': ./Modules/posixmodule.c:5193: storage size of `st' isn't known ./Modules/posixmodule.c:5202: type of formal parameter 1 is incomplete ./Modules/posixmodule.c:5193: warning: unused variable `st' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 12:23 Message: Logged In: YES user_id=21627 This is a bug caused by the Solaris/gcc combination. Solaris headers have a bug that only shows up if you use a non-system compiler. gcc 3.2 eliminates the problem by sufficiently emulating the system compiler, so the problem is only present in older gcc releases. I fixed this by disabling LFS in those cases; committed as configure 1.340; configure.in 1.351; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618095&group_id=5470 From noreply@sourceforge.net Fri Oct 4 11:25:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 03:25:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-617878 ] parse error compiling on Solaris Message-ID: Bugs item #617878, was opened at 2002-10-03 04:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617878&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: parse error compiling on Solaris Initial Comment: Attempting to compile current CVS version on Solaris 2.6 generates a parse error: In file included from Python/thread_pthread.h:9, from Python/thread.c:104: /usr/include/pthread.h:159: parse error before `destructor' /usr/include/pthread.h:159: parse error before `)' make: *** [Python/thread.o] Error 1 $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-04 12:25 Message: Logged In: YES user_id=21627 Fixed with #618347. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 10:21 Message: Logged In: YES user_id=21627 That's a bug in the pthread headers of Solaris 2.6. You need to make the same change to thread_pthread.h that is done for APPLE. Would you like to design a patch to solve that problem? It would have to apply only to 2.6; later systems don't use destructor in the header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=617878&group_id=5470 From noreply@sourceforge.net Fri Oct 4 12:15:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 04:15:48 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 09:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 6 Submitted By: Michael Hudson (mwh) >Assigned to: M.-A. Lemburg (lemburg) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-04 11:15 Message: Logged In: YES user_id=38388 MWH: My first paragraph was refering to Martin's suggestion to use eval() for mapping literal strings to objects. Please take this to the python-dev mailing list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 09:00 Message: Logged In: YES user_id=6656 MAL: I don't understand your first paragraph at all. The {sys.,}source_encoding variable might work, but it would be a dreadful hack for my purposes. Using eval() is already a nasty hack, IMHO. I agree a mailing list is a more civilised interface than a web browser... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 19:21 Message: Logged In: YES user_id=21627 That would not be correct. If you have a (plain) string literal, it would end up encoded as UTF-8, whereas the original source encoding was, say, Latin-1. People will be confused if string literals don't come out in the expected encoding in interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-03 18:11 Message: Logged In: YES user_id=38388 I believe the correct way to handle this would be to have eval() accept Unicode and then convert it to UTF-8 for the parser to process. The PEP only talks about compile() which should accept Unicode objects, but eval() is certainly a candidate too. About the source_encoding idea: wouldn't it be better to define this for interactive use in the sys module ? A Python startup script could then be used to set this variable in interactive mode. BTW, it's better to discuss these things on python-dev than in these small textareas... IMHO, at least. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:55 Message: Logged In: YES user_id=21627 I see. For a different reason (interactive mode), I have been contemplating to recognize a variable source_encoding in globals(), which would be set in interactive mode to the terminal's encoding, so that input of non-ASCII Unicode literals would "work", without having to type an encoding declaration each time. I believe such a mechanism could also solve this problem; callers of eval would have to set the global. What do you think? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 16:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 16:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Fri Oct 4 13:51:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 05:51:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-607253 ] header file problems Message-ID: Bugs item #607253, was opened at 2002-09-10 06:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: header file problems Initial Comment: In connection with the Boost.Python library we are having problems due to missing extern "C" in some header files. This has prompted me to systematically look at all header files on the release22-maint branch and on the CVS trunk. The summary is shown below. The most severe problem are the missing extern "C" on the release-22-maint branch. Fortunately, this is fixed already on the CVS trunk. The next important problem is that the include guards are missing in pymactoolbox.h (both trunk and maint branch). I am not clear if there have to be include guards in files that only contain #defines (such as patchlevel.h) but having them would seem safer to me. Finally, the include guards in two files are not prefixed with Py_, Again, it would seem safter to me (reduce the chances of name clashes) if all Python include guards were consistently prefixed with Py_ . Ralf Python release22-maint cvs branch: extern "C" missing in: cStringIO.h descrobject.h iterobject.h include guards missing in: descrobject.h graminit.h iterobject.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h Python cvs head (Sep 9): include guards missing in: graminit.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-04 08:51 Message: Logged In: YES user_id=33168 Backported the include guards/extern "C" for: * cStringIO.h 2.15.18.1 * descrobject.h 2.8.8.1 * iterobject.h 1.3.20.1 Fixed include guard prefix: * complexobject.h 2.11, 2.9.12.12.1 * cStringIO.h 2.9, 2.15.18.2 I'm leaving open for now, so I can discuss adding include guards for the other files (graminit.h, patchlevel.h, pyconfig.h). ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-09-24 00:56 Message: Logged In: YES user_id=71407 Patches for python-release22-maint as requested by Tim and Guido. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-10 08:34 Message: Logged In: YES user_id=45365 I've added the include guard to pymactoolbox.h. I've also added include guards and extern "C" constructs (where needed) to the include files in Mac/Include. The other ones I leave to someone else, esp. because I'm not sure things like graminit.h need them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 From noreply@sourceforge.net Fri Oct 4 16:07:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 08:07:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-618593 ] Windows binary missing IPv6 support Message-ID: Bugs item #618593, was opened at 2002-10-04 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toni Garcia (zolty) Assigned to: Nobody/Anonymous (nobody) Summary: Windows binary missing IPv6 support Initial Comment: The Windows binary build from www.python.org appears to be missing IPv6 support. The IP configuration in my Windows XP + Service Pack 1: C:\Documents and Settings\zolty>ipconfig Configuración IP de Windows Adaptador Ethernet Conexión de área local : Sufijo de conexión específica DNS : Dirección IP. . . . . . . . . . . : 192.168.0.2 Máscara de subred . . . . . . . . : 255.255.255.0 Dirección IP. . . . . . . . . . . : fe80::200:1cff:fe04:cae6%4 Puerta de enlace predeterminada : 192.168.0.1 Here's an example of a socket with ipv6 protocol/family: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> a=socket.socket (socket.AF_INET6,socket.SOCK_STREAM) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'AF_INET6' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 From noreply@sourceforge.net Fri Oct 4 16:08:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 08:08:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-618594 ] Connecting to IPv4 addrs from IPv6 socke Message-ID: Bugs item #618594, was opened at 2002-10-04 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting to IPv4 addrs from IPv6 socke Initial Comment: You can connect to a IPv4 addr "a.b.c.d" from a IPv6 socket simply connecting to "::FFFF:a.b.c.d" IPv6 address. When you issue a "connect" call on a IPv6 socket using a pure IPv4 addr "a.b.c.d", this format SHOULD be converted "automagically" to "::FFFF:a.b.c.d", intenally. Currently, this operation gives an error. The real problem is "connect" call using a hostname (not resolved to a IPv4 or IPv6 addr). Since I don't know to which IP address type the host will resolve, I think the correct course should be to promote IPv4 to IPv6 address space (if the socket is IPv6) and to connect normally. Obviously, trying to connect to a IPv6 addr using a IPv4 socket should fail, like just now. When a hostname used in "connect" call resolves to both IPv4 and IPv6 addresses, it would use IPv4 if the socket is IPv4, and IPv6 if the socket is IPv6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 From noreply@sourceforge.net Fri Oct 4 16:11:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 08:11:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-618593 ] Windows binary missing IPv6 support Message-ID: Bugs item #618593, was opened at 2002-10-04 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 >Category: Windows >Group: Python 2.2.1 Status: Open Resolution: None >Priority: 9 Submitted By: Toni Garcia (zolty) Assigned to: Nobody/Anonymous (nobody) Summary: Windows binary missing IPv6 support Initial Comment: The Windows binary build from www.python.org appears to be missing IPv6 support. The IP configuration in my Windows XP + Service Pack 1: C:\Documents and Settings\zolty>ipconfig Configuración IP de Windows Adaptador Ethernet Conexión de área local : Sufijo de conexión específica DNS : Dirección IP. . . . . . . . . . . : 192.168.0.2 Máscara de subred . . . . . . . . : 255.255.255.0 Dirección IP. . . . . . . . . . . : fe80::200:1cff:fe04:cae6%4 Puerta de enlace predeterminada : 192.168.0.1 Here's an example of a socket with ipv6 protocol/family: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> a=socket.socket (socket.AF_INET6,socket.SOCK_STREAM) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'AF_INET6' >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 From noreply@sourceforge.net Fri Oct 4 16:33:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 08:33:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-618608 ] getaddrinfo and numeric ports Message-ID: Bugs item #618608, was opened at 2002-10-04 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618608&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: getaddrinfo and numeric ports Initial Comment: Python 2.2.1 here. Documentación for "socket.getaddrinfo()" says that "port" can be "a string service name (like ``http''), a numeric port number or None.". String service name and "None" work fine. But numeric ports are not soported under LINUX RedHat: >>> socket.getaddrinfo("localhost",80) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-8, 'Servname not supported for ai_socktype') It works fine under Solaris 2.5.1 and Win98. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618608&group_id=5470 From noreply@sourceforge.net Fri Oct 4 16:50:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 08:50:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-618615 ] thread_pthread:undefined ref to sem_post Message-ID: Bugs item #618615, was opened at 2002-10-04 10:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618615&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: thread_pthread:undefined ref to sem_post Initial Comment: On Solaris 2.6, thread_pthread.h:412: undefined reference to 'sem_post' gcc version 2.95.2 19991024 (release) ar cr libpython2.3.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/symtablemodule.o Modules/xxsubtype.o ranlib libpython2.3.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.3.a -lsocket -lnsl -ldl -lpthread -lm libpython2.3.a(thread.o): In function `PyThread_allocate_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:334: undefined reference to `sem_init' libpython2.3.a(thread.o): In function `PyThread_free_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:358: undefined reference to `sem_destroy' libpython2.3.a(thread.o): In function `PyThread_acquire_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:387: undefined reference to `sem_wait' /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:389: undefined reference to `sem_trywait' libpython2.3.a(thread.o): In function `PyThread_release_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:412: undefined reference to `sem_post' collect2: ld returned 1 exit status make: *** [python] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618615&group_id=5470 From noreply@sourceforge.net Fri Oct 4 17:02:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 09:02:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Fri Oct 4 17:24:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 09:24:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-618633 ] sys.execpthook not used in threads Message-ID: Bugs item #618633, was opened at 2002-10-04 16:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618633&group_id=5470 Category: Threads Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: David Thiede (dthiede) Assigned to: Nobody/Anonymous (nobody) Summary: sys.execpthook not used in threads Initial Comment: The sys.excepthook feature does not seem to be used when exceptions are triggered in threads. It does work in the MainThread. It would be real nice if this feature would extended to threads. The only thing that I can find on the lists bug or patch seems to be Ping's orginal patch and the followup posts to that patch. Redhat 7.3 Python 2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618633&group_id=5470 From noreply@sourceforge.net Fri Oct 4 20:11:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 12:11:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-618704 ] Use C3 MRO algorithm Message-ID: Bugs item #618704, was opened at 2002-10-04 15:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618704&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Use C3 MRO algorithm Initial Comment: In http://mail.python.org/pipermail/python-dev/2002-October/029035.html and following messages, Samuele Pedroni argues that the current MRO algorithm has some unexpected properties, and that the "naive" algorithm described in the docs (keep the last occurrence in a depth-first search) is not monotonic. The current algorithm is monotonic. A better algorithm, named C3, is described in this paper: http://www.webcom.com/haahr/dylan/linearization-oopsla96.html I believe that the current algorithm is the same as L*[LOOPS] mentioned in this paper (though I have no proof). The paper argues convincingly that C3 is better than L*[LOOPS], so I propose to use C3 starting in Python 2.3. This can cause backwards compatibilities in certain cases, but the new algorithm matches intuition better than the current algorithm. (The naive algorithm from the docs is unacceptable due to its non-monotonicity.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618704&group_id=5470 From noreply@sourceforge.net Fri Oct 4 21:16:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 13:16:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 15:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-04 15:16 Message: Logged In: YES user_id=80475 It's starting to look as if any sort of optimization effort will take more human time to create, test, and review than it could ever save in computer time. Can this be closed? ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-12 16:13 Message: Logged In: YES user_id=292741 OK, i'll try that when I have time. The problem is, you can't do [None]*1000000 over and over again for 10 seconds unless you also destroy the lists, there isn't enough RAM - and I was trying not to count the dispose time, which of course is also dependent on the list length. I was calling calling clock() immediately before and after the operation, and accumulating the differences, thus excluding the rest of the loop with the list delete. any uncertainty in clock() should in principle average out over a lot of reps. For what it's worth, the results were reasonably repeatable from run to run (maybe 5%) and very linear with respect to changing the '*1000000' factor. I know i'm effectively timing one call to clock() as part of the timed code; but that won't change with the list size and can thus be factored out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 11:43 Message: Logged In: YES user_id=21627 Please don't invoke clock() twice per iteration. The standard timing procedure is iterations = [None] * niter start = clock() for i in iterations: actions_to_time total = clock() - start That way, you don't measure the time it takes to create the range object. Also, don't trust any measurements that have a total time of less then 10s (running it for a minute is even better). With this algorithm, please re-report the two totals, and the number of iterations. Run it several times in a row, to see how results vary. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 18:10 Message: Logged In: YES user_id=292741 using this test code, and changing the 1000000, I have found that it adds an additional 40 nsec for each additional copy of the None. This doesn't change noticeably when I add the 'improvement'. If I change it to []*whatever, then the old implementation needs 5 ns extra for each non-copy (and the new one isn't sensitive). This is telling me that most of the time in the [None]*lots is in the PyList_New() to get the list. So I went and made a variant of PyList_New which doesn't clear the list, and found that [None]*1000000 takes 22msec instead of the 40 it used to take. This doesn't make too much sense, looking at the code; maybe cache effects. Time to go home now... ------------------------- def timeit(): from time import clock t0 = clock() tin = 0 niter = 50 for i in range(niter): ta,p,tb = clock(),[None]*1000000,clock() tin += tb-ta p = 0 # deallocate list t0 = clock()-t0 print "avg. time = ", tin/niter print "avg. overhead = ", t0/niter timeit() --------------------- ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 13:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 13:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 04:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 20:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Fri Oct 4 21:53:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 13:53:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads Message-ID: Bugs item #566037, was opened at 2002-06-07 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470 Category: Threads Group: Python 2.2.1 Status: Open Resolution: None Priority: 3 Submitted By: Martin Stoufer (mstoufer) Assigned to: Nobody/Anonymous (nobody) Summary: Popen exectuion blocking w/threads Initial Comment: The following unit test hangs after the first two lines of output. This is wholly reproducible (for us) under 2.2.1 and totaly unreproducible under 2.1. We have both interpreters installed on a RH7.2 PC with linkings against the apparent same /lib/libthread.so.0 import os, threading,time, sys def read_output(self, cmd, timeout): print "run: %s" % cmd (inf,outf) = os.popen4(cmd) print "started! out_fd=%d" % outf.fileno() while 1: line = outf.readline() if line == "": break print len(line),line sys.stdout.flush() return if __name__ == '__main__': thr = threading.Thread(target=read_output,args=(1,"ping -c 5 www.mit.edu",0)) thr.start() print "Started thread" while 1: time.sleep(1) mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2} /usr/local/bin/python2.1: libpthread.so.0 => /lib/libpthread.so.0 (0x40029000) libdl.so.2 => /lib/libdl.so.2 (0x40040000) libutil.so.1 => /lib/libutil.so.1 (0x40044000) libstdc++-libc6.1-2.so.3 => /usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000) libm.so.6 => /lib/libm.so.6 (0x4008f000) libc.so.6 => /lib/libc.so.6 (0x400b1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/local/bin/python2.2: libdl.so.2 => /lib/libdl.so.2 (0x40029000) libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000) libutil.so.1 => /lib/libutil.so.1 (0x40044000) libm.so.6 => /lib/libm.so.6 (0x40047000) libc.so.6 => /lib/libc.so.6 (0x4006a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ---------------------------------------------------------------------- Comment By: Becky Burwell (burwell) Date: 2002-10-04 13:53 Message: Logged In: YES user_id=348250 We have the same problem in RedHat 7.3 with Python 2.2 using ping in a thread. If I do a popen or just os.system in a thread, the ping hangs for hosts that are not responding (works fine IF the host is up.) Note: this code works fine in Python 2.1.1 and works fine not in a thread in Python 2.2 Also: if the command prints out lots of output there is still a hang. The ping command has to be killed with a kill -9. #!/usr/bin/python2 import os,threading class MyHost(threading.Thread): def __init__(self): threading.Thread.__init__(self) def run(self): ping_string = "/bin/ping -q -c 1 -w 2 hostthatisdown" print "about to execute ping string %s\n" % ping_string f = os.popen (ping_string,"r") result = f.close () print "result is ",result thread = MyHost() thread.start () ---------------------------------------------------------------------- Comment By: Martin Stoufer (mcstoufer) Date: 2002-07-24 09:31 Message: Logged In: YES user_id=243169 I've found that using the generic os.popen() call and just reading everything back to be a somewhat equitable fix. The returned object is file like and the .close() call on it at the end seems to clean up house pretty well. Before, with a Popen4() object, I was getting a lot of processes. Now they all go away nicely. I'd be willing to follow up in person with anyone here, MCStoufer@lbl.gov ---------------------------------------------------------------------- Comment By: Zoran Bosnjak (zoranbosnjak) Date: 2002-07-24 06:28 Message: Logged In: YES user_id=583469 I have the same problem with python2.2 (the child process does not terminate on SIGTERM - it only terminates on SIGKILL). The same program works (terminates) fine with python2.1.1 (all other libs are the same). Here is my simple testfile: #!/usr/bin/env python2.2 import os, time, signal, threading, string from popen2 import Popen3, Popen4 pid = 0 def run(): global pid f = Popen4('ping localhost') pid = f.pid while 1: s = f.fromchild.readline() if not s: break t = threading.Thread(target=run) t.start() time.sleep(10) print 'timeout' os.kill(pid, signal.SIGTERM) t.join() print 'bye' ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-11 21:16 Message: Logged In: YES user_id=6380 Anything is possible. I suggest asking for help in a Linux threading guru forum. ---------------------------------------------------------------------- Comment By: Martin Stoufer (mcstoufer) Date: 2002-06-11 21:10 Message: Logged In: YES user_id=243169 This same issue arises when any subprocess is declared that makes more than 1 network read/write. From the system side, the Ping process is simply sleeping; we feel that the process is looking for the pipe to empty so it can finish it's write to stdout. Replacing cmd with 'ping -c 1 www.mit.edu' works everytime. Replacing cmd with 'echo\'Hello. world\'' works as well. We have beeen using a therading model similar to this under 2.1 and it has been quite robust in its execution. Is it possible that this is a compile-time issue with the thread linking? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 12:39 Message: Logged In: YES user_id=6380 Mixing forks and threads is often asking for trouble... Does this also hang with another command that produces more than two lines of output, or is it limited to ping? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-09 01:32 Message: Logged In: YES user_id=21627 I can't reproduce this on a SuSE system, either (which has glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-06-07 22:42 Message: Logged In: YES user_id=14198 Just noting that current CVS Python works fine on Windows, but also hangs on RH7. My Linux debuggings skills are such that I can offer no further help ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470 From noreply@sourceforge.net Fri Oct 4 22:20:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 14:20:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads Message-ID: Bugs item #566037, was opened at 2002-06-07 20:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470 Category: Threads Group: Python 2.2.1 Status: Open Resolution: None >Priority: 1 Submitted By: Martin Stoufer (mstoufer) Assigned to: Nobody/Anonymous (nobody) Summary: Popen exectuion blocking w/threads Initial Comment: The following unit test hangs after the first two lines of output. This is wholly reproducible (for us) under 2.2.1 and totaly unreproducible under 2.1. We have both interpreters installed on a RH7.2 PC with linkings against the apparent same /lib/libthread.so.0 import os, threading,time, sys def read_output(self, cmd, timeout): print "run: %s" % cmd (inf,outf) = os.popen4(cmd) print "started! out_fd=%d" % outf.fileno() while 1: line = outf.readline() if line == "": break print len(line),line sys.stdout.flush() return if __name__ == '__main__': thr = threading.Thread(target=read_output,args=(1,"ping -c 5 www.mit.edu",0)) thr.start() print "Started thread" while 1: time.sleep(1) mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2} /usr/local/bin/python2.1: libpthread.so.0 => /lib/libpthread.so.0 (0x40029000) libdl.so.2 => /lib/libdl.so.2 (0x40040000) libutil.so.1 => /lib/libutil.so.1 (0x40044000) libstdc++-libc6.1-2.so.3 => /usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000) libm.so.6 => /lib/libm.so.6 (0x4008f000) libc.so.6 => /lib/libc.so.6 (0x400b1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/local/bin/python2.2: libdl.so.2 => /lib/libdl.so.2 (0x40029000) libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000) libutil.so.1 => /lib/libutil.so.1 (0x40044000) libm.so.6 => /lib/libm.so.6 (0x40047000) libc.so.6 => /lib/libc.so.6 (0x4006a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-04 17:20 Message: Logged In: YES user_id=6380 I can reproduce this in Python 2.3, by the way. I'm just not sure that there's anything that Python can do to avoid this -- it feels like a bug in libc (or in ping). Lowering priority because of that. ---------------------------------------------------------------------- Comment By: Becky Burwell (burwell) Date: 2002-10-04 16:53 Message: Logged In: YES user_id=348250 We have the same problem in RedHat 7.3 with Python 2.2 using ping in a thread. If I do a popen or just os.system in a thread, the ping hangs for hosts that are not responding (works fine IF the host is up.) Note: this code works fine in Python 2.1.1 and works fine not in a thread in Python 2.2 Also: if the command prints out lots of output there is still a hang. The ping command has to be killed with a kill -9. #!/usr/bin/python2 import os,threading class MyHost(threading.Thread): def __init__(self): threading.Thread.__init__(self) def run(self): ping_string = "/bin/ping -q -c 1 -w 2 hostthatisdown" print "about to execute ping string %s\n" % ping_string f = os.popen (ping_string,"r") result = f.close () print "result is ",result thread = MyHost() thread.start () ---------------------------------------------------------------------- Comment By: Martin Stoufer (mcstoufer) Date: 2002-07-24 12:31 Message: Logged In: YES user_id=243169 I've found that using the generic os.popen() call and just reading everything back to be a somewhat equitable fix. The returned object is file like and the .close() call on it at the end seems to clean up house pretty well. Before, with a Popen4() object, I was getting a lot of processes. Now they all go away nicely. I'd be willing to follow up in person with anyone here, MCStoufer@lbl.gov ---------------------------------------------------------------------- Comment By: Zoran Bosnjak (zoranbosnjak) Date: 2002-07-24 09:28 Message: Logged In: YES user_id=583469 I have the same problem with python2.2 (the child process does not terminate on SIGTERM - it only terminates on SIGKILL). The same program works (terminates) fine with python2.1.1 (all other libs are the same). Here is my simple testfile: #!/usr/bin/env python2.2 import os, time, signal, threading, string from popen2 import Popen3, Popen4 pid = 0 def run(): global pid f = Popen4('ping localhost') pid = f.pid while 1: s = f.fromchild.readline() if not s: break t = threading.Thread(target=run) t.start() time.sleep(10) print 'timeout' os.kill(pid, signal.SIGTERM) t.join() print 'bye' ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-12 00:16 Message: Logged In: YES user_id=6380 Anything is possible. I suggest asking for help in a Linux threading guru forum. ---------------------------------------------------------------------- Comment By: Martin Stoufer (mcstoufer) Date: 2002-06-12 00:10 Message: Logged In: YES user_id=243169 This same issue arises when any subprocess is declared that makes more than 1 network read/write. From the system side, the Ping process is simply sleeping; we feel that the process is looking for the pipe to empty so it can finish it's write to stdout. Replacing cmd with 'ping -c 1 www.mit.edu' works everytime. Replacing cmd with 'echo\'Hello. world\'' works as well. We have beeen using a therading model similar to this under 2.1 and it has been quite robust in its execution. Is it possible that this is a compile-time issue with the thread linking? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 15:39 Message: Logged In: YES user_id=6380 Mixing forks and threads is often asking for trouble... Does this also hang with another command that produces more than two lines of output, or is it limited to ping? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-09 04:32 Message: Logged In: YES user_id=21627 I can't reproduce this on a SuSE system, either (which has glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-06-08 01:42 Message: Logged In: YES user_id=14198 Just noting that current CVS Python works fine on Windows, but also hangs on RH7. My Linux debuggings skills are such that I can offer no further help ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470 From noreply@sourceforge.net Fri Oct 4 23:01:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 15:01:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads Message-ID: Bugs item #566037, was opened at 2002-06-07 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470 Category: Threads Group: Python 2.2.1 Status: Open Resolution: None Priority: 1 Submitted By: Martin Stoufer (mstoufer) Assigned to: Nobody/Anonymous (nobody) Summary: Popen exectuion blocking w/threads Initial Comment: The following unit test hangs after the first two lines of output. This is wholly reproducible (for us) under 2.2.1 and totaly unreproducible under 2.1. We have both interpreters installed on a RH7.2 PC with linkings against the apparent same /lib/libthread.so.0 import os, threading,time, sys def read_output(self, cmd, timeout): print "run: %s" % cmd (inf,outf) = os.popen4(cmd) print "started! out_fd=%d" % outf.fileno() while 1: line = outf.readline() if line == "": break print len(line),line sys.stdout.flush() return if __name__ == '__main__': thr = threading.Thread(target=read_output,args=(1,"ping -c 5 www.mit.edu",0)) thr.start() print "Started thread" while 1: time.sleep(1) mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2} /usr/local/bin/python2.1: libpthread.so.0 => /lib/libpthread.so.0 (0x40029000) libdl.so.2 => /lib/libdl.so.2 (0x40040000) libutil.so.1 => /lib/libutil.so.1 (0x40044000) libstdc++-libc6.1-2.so.3 => /usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000) libm.so.6 => /lib/libm.so.6 (0x4008f000) libc.so.6 => /lib/libc.so.6 (0x400b1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) /usr/local/bin/python2.2: libdl.so.2 => /lib/libdl.so.2 (0x40029000) libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000) libutil.so.1 => /lib/libutil.so.1 (0x40044000) libm.so.6 => /lib/libm.so.6 (0x40047000) libc.so.6 => /lib/libc.so.6 (0x4006a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ---------------------------------------------------------------------- Comment By: Becky Burwell (burwell) Date: 2002-10-04 15:01 Message: Logged In: YES user_id=348250 FYI: this happens if the program is a bash shell which calls ping. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-04 14:20 Message: Logged In: YES user_id=6380 I can reproduce this in Python 2.3, by the way. I'm just not sure that there's anything that Python can do to avoid this -- it feels like a bug in libc (or in ping). Lowering priority because of that. ---------------------------------------------------------------------- Comment By: Becky Burwell (burwell) Date: 2002-10-04 13:53 Message: Logged In: YES user_id=348250 We have the same problem in RedHat 7.3 with Python 2.2 using ping in a thread. If I do a popen or just os.system in a thread, the ping hangs for hosts that are not responding (works fine IF the host is up.) Note: this code works fine in Python 2.1.1 and works fine not in a thread in Python 2.2 Also: if the command prints out lots of output there is still a hang. The ping command has to be killed with a kill -9. #!/usr/bin/python2 import os,threading class MyHost(threading.Thread): def __init__(self): threading.Thread.__init__(self) def run(self): ping_string = "/bin/ping -q -c 1 -w 2 hostthatisdown" print "about to execute ping string %s\n" % ping_string f = os.popen (ping_string,"r") result = f.close () print "result is ",result thread = MyHost() thread.start () ---------------------------------------------------------------------- Comment By: Martin Stoufer (mcstoufer) Date: 2002-07-24 09:31 Message: Logged In: YES user_id=243169 I've found that using the generic os.popen() call and just reading everything back to be a somewhat equitable fix. The returned object is file like and the .close() call on it at the end seems to clean up house pretty well. Before, with a Popen4() object, I was getting a lot of processes. Now they all go away nicely. I'd be willing to follow up in person with anyone here, MCStoufer@lbl.gov ---------------------------------------------------------------------- Comment By: Zoran Bosnjak (zoranbosnjak) Date: 2002-07-24 06:28 Message: Logged In: YES user_id=583469 I have the same problem with python2.2 (the child process does not terminate on SIGTERM - it only terminates on SIGKILL). The same program works (terminates) fine with python2.1.1 (all other libs are the same). Here is my simple testfile: #!/usr/bin/env python2.2 import os, time, signal, threading, string from popen2 import Popen3, Popen4 pid = 0 def run(): global pid f = Popen4('ping localhost') pid = f.pid while 1: s = f.fromchild.readline() if not s: break t = threading.Thread(target=run) t.start() time.sleep(10) print 'timeout' os.kill(pid, signal.SIGTERM) t.join() print 'bye' ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-11 21:16 Message: Logged In: YES user_id=6380 Anything is possible. I suggest asking for help in a Linux threading guru forum. ---------------------------------------------------------------------- Comment By: Martin Stoufer (mcstoufer) Date: 2002-06-11 21:10 Message: Logged In: YES user_id=243169 This same issue arises when any subprocess is declared that makes more than 1 network read/write. From the system side, the Ping process is simply sleeping; we feel that the process is looking for the pipe to empty so it can finish it's write to stdout. Replacing cmd with 'ping -c 1 www.mit.edu' works everytime. Replacing cmd with 'echo\'Hello. world\'' works as well. We have beeen using a therading model similar to this under 2.1 and it has been quite robust in its execution. Is it possible that this is a compile-time issue with the thread linking? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 12:39 Message: Logged In: YES user_id=6380 Mixing forks and threads is often asking for trouble... Does this also hang with another command that produces more than two lines of output, or is it limited to ping? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-09 01:32 Message: Logged In: YES user_id=21627 I can't reproduce this on a SuSE system, either (which has glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-06-07 22:42 Message: Logged In: YES user_id=14198 Just noting that current CVS Python works fine on Windows, but also hangs on RH7. My Linux debuggings skills are such that I can offer no further help ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470 From noreply@sourceforge.net Sat Oct 5 01:05:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Oct 2002 17:05:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-531145 ] socket.sslerror is not a socket.error Message-ID: Bugs item #531145, was opened at 2002-03-18 00:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: socket.sslerror is not a socket.error Initial Comment: Python 2.1.2 (#1, Mar 16 2002, 00:56:55) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import socket >>> socket.sslerror >>> try: raise socket.sslerror ... except socket.error: pass ... Traceback (most recent call last): File "", line 1, in ? socket.sslerror >>> ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-05 02:05 Message: Logged In: YES user_id=163326 So do you propose to make socket.sslerror a subclass of socket.error. Is this desirable? I'm not sure. Is it work? Yes. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-03-18 21:23 Message: Logged In: YES user_id=9205 The documentation says for socket.error: "This exception is raised for socket- or address-related errors." I think socket.sslerror is such an error, because then you can write try: sock.write("") # could be ssl-socket except socket.error: pass The other way would be _exceptions = [socket.error] if hasattr(socket, "sslerror"): _exceptions.append(socket.sslerror) try: sock.write("") except _exceptions: pass Anyway, I assume this is a minor "bug". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-18 11:44 Message: Logged In: YES user_id=21627 Why is this a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470 From noreply@sourceforge.net Sat Oct 5 10:50:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 02:50:46 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-618633 ] sys.execpthook not used in threads Message-ID: Feature Requests item #618633, was opened at 2002-10-04 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618633&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Thiede (dthiede) Assigned to: Nobody/Anonymous (nobody) Summary: sys.execpthook not used in threads Initial Comment: The sys.excepthook feature does not seem to be used when exceptions are triggered in threads. It does work in the MainThread. It would be real nice if this feature would extended to threads. The only thing that I can find on the lists bug or patch seems to be Ping's orginal patch and the followup posts to that patch. Redhat 7.3 Python 2.2 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 11:50 Message: Logged In: YES user_id=21627 Each thread has its own except hook, so you have to set it for each thread. If it is set in a thread, it is also used there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618633&group_id=5470 From noreply@sourceforge.net Sat Oct 5 10:52:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 02:52:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-618615 ] thread_pthread:undefined ref to sem_post Message-ID: Bugs item #618615, was opened at 2002-10-04 17:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618615&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) >Assigned to: Martin v. Löwis (loewis) Summary: thread_pthread:undefined ref to sem_post Initial Comment: On Solaris 2.6, thread_pthread.h:412: undefined reference to 'sem_post' gcc version 2.95.2 19991024 (release) ar cr libpython2.3.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/symtablemodule.o Modules/xxsubtype.o ranlib libpython2.3.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.3.a -lsocket -lnsl -ldl -lpthread -lm libpython2.3.a(thread.o): In function `PyThread_allocate_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:334: undefined reference to `sem_init' libpython2.3.a(thread.o): In function `PyThread_free_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:358: undefined reference to `sem_destroy' libpython2.3.a(thread.o): In function `PyThread_acquire_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:387: undefined reference to `sem_wait' /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:389: undefined reference to `sem_trywait' libpython2.3.a(thread.o): In function `PyThread_release_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:412: undefined reference to `sem_post' collect2: ld returned 1 exit status make: *** [python] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618615&group_id=5470 From noreply@sourceforge.net Sat Oct 5 10:56:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 02:56:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-618593 ] Windows binary missing IPv6 support Message-ID: Bugs item #618593, was opened at 2002-10-04 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 Category: Windows >Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Toni Garcia (zolty) Assigned to: Nobody/Anonymous (nobody) Summary: Windows binary missing IPv6 support Initial Comment: The Windows binary build from www.python.org appears to be missing IPv6 support. The IP configuration in my Windows XP + Service Pack 1: C:\Documents and Settings\zolty>ipconfig Configuración IP de Windows Adaptador Ethernet Conexión de área local : Sufijo de conexión específica DNS : Dirección IP. . . . . . . . . . . : 192.168.0.2 Máscara de subred . . . . . . . . : 255.255.255.0 Dirección IP. . . . . . . . . . . : fe80::200:1cff:fe04:cae6%4 Puerta de enlace predeterminada : 192.168.0.1 Here's an example of a socket with ipv6 protocol/family: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> a=socket.socket (socket.AF_INET6,socket.SOCK_STREAM) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'AF_INET6' >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 11:56 Message: Logged In: YES user_id=21627 While your observation is correct, I fail to see the importance of this problem. Please understand that what you want is unimplementable with MSVC6, since it does not provide the necessary header files and library routines. IPv6 support is only available if you use CVS Python, and VC.NET. I have changed the group to Python 2.3; for Python 2.2, this would be a new feature, and thus won't be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 From noreply@sourceforge.net Sat Oct 5 10:57:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 02:57:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 18:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 11:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Sat Oct 5 11:06:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 03:06:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-618608 ] getaddrinfo and numeric ports Message-ID: Bugs item #618608, was opened at 2002-10-04 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618608&group_id=5470 Category: Extension Modules Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: getaddrinfo and numeric ports Initial Comment: Python 2.2.1 here. Documentación for "socket.getaddrinfo()" says that "port" can be "a string service name (like ``http''), a numeric port number or None.". String service name and "None" work fine. But numeric ports are not soported under LINUX RedHat: >>> socket.getaddrinfo("localhost",80) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-8, 'Servname not supported for ai_socktype') It works fine under Solaris 2.5.1 and Win98. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 12:06 Message: Logged In: YES user_id=21627 You have to provide a socket type if you want to specify a port number; without a socket type (SOCK_STREAM or SOCK_DGRAM), the port number is meaningless. So the proper call is socket.getaddrinfo("localhost",80,0,socket.SOCK_STREAM) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618608&group_id=5470 From noreply@sourceforge.net Sat Oct 5 11:11:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 03:11:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-618594 ] Connecting to IPv4 addrs from IPv6 socke Message-ID: Bugs item #618594, was opened at 2002-10-04 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting to IPv4 addrs from IPv6 socke Initial Comment: You can connect to a IPv4 addr "a.b.c.d" from a IPv6 socket simply connecting to "::FFFF:a.b.c.d" IPv6 address. When you issue a "connect" call on a IPv6 socket using a pure IPv4 addr "a.b.c.d", this format SHOULD be converted "automagically" to "::FFFF:a.b.c.d", intenally. Currently, this operation gives an error. The real problem is "connect" call using a hostname (not resolved to a IPv4 or IPv6 addr). Since I don't know to which IP address type the host will resolve, I think the correct course should be to promote IPv4 to IPv6 address space (if the socket is IPv6) and to connect normally. Obviously, trying to connect to a IPv6 addr using a IPv4 socket should fail, like just now. When a hostname used in "connect" call resolves to both IPv4 and IPv6 addresses, it would use IPv4 if the socket is IPv4, and IPv6 if the socket is IPv6. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 12:11 Message: Logged In: YES user_id=21627 I fail to see a Python bug here. All calls are delegated to the C library, which delegates most of it to the kernel. So complain to your operating system vendor. I don't think your complaint is valid, though: the sockaddr is computed by looking at its format. If it does not contains a colon, it is not an AF_INET6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 From noreply@sourceforge.net Sat Oct 5 14:41:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 06:41:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-05 13:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 09:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Sat Oct 5 18:44:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 10:44:20 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-618633 ] sys.execpthook not used in threads Message-ID: Feature Requests item #618633, was opened at 2002-10-04 16:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618633&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Thiede (dthiede) Assigned to: Nobody/Anonymous (nobody) Summary: sys.execpthook not used in threads Initial Comment: The sys.excepthook feature does not seem to be used when exceptions are triggered in threads. It does work in the MainThread. It would be real nice if this feature would extended to threads. The only thing that I can find on the lists bug or patch seems to be Ping's orginal patch and the followup posts to that patch. Redhat 7.3 Python 2.2 ---------------------------------------------------------------------- >Comment By: David Thiede (dthiede) Date: 2002-10-05 17:44 Message: Logged In: YES user_id=427491 There is no indication of a callback hook in the Thread class. The source for threading.py shows a _print_exc handle that I had tested. It is possible to override the name and get most of the desired behaviour but there are problems. The following code is from threading.__bootstrap() _print_exc(file=s) _sys.stderr.write("Exception in thread %s:\n%s\n" % (self.getName(), s.getvalue())) This still generates some output to standard error which is not desireable. It is also a global setting which is not what you implied. Your statement is that "each thread has a hook" is certainly not apparent. in the code. This API is also different than what is available globally in the sys module.except() hook. I also checked the cgitb.py module and it also does't handle threads, apparently. I realize that there are other ways to handle intercepting and formatting excetpion output but the callback scheme was so nice. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 09:50 Message: Logged In: YES user_id=21627 Each thread has its own except hook, so you have to set it for each thread. If it is set in a thread, it is also used there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618633&group_id=5470 From noreply@sourceforge.net Sat Oct 5 18:44:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 10:44:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Sat Oct 5 22:04:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 14:04:36 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-618633 ] sys.execpthook not used in threads Message-ID: Feature Requests item #618633, was opened at 2002-10-04 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618633&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Thiede (dthiede) Assigned to: Nobody/Anonymous (nobody) Summary: sys.execpthook not used in threads Initial Comment: The sys.excepthook feature does not seem to be used when exceptions are triggered in threads. It does work in the MainThread. It would be real nice if this feature would extended to threads. The only thing that I can find on the lists bug or patch seems to be Ping's orginal patch and the followup posts to that patch. Redhat 7.3 Python 2.2 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 23:04 Message: Logged In: YES user_id=21627 I see what you mean. Please ignore my previous comment. ---------------------------------------------------------------------- Comment By: David Thiede (dthiede) Date: 2002-10-05 19:44 Message: Logged In: YES user_id=427491 There is no indication of a callback hook in the Thread class. The source for threading.py shows a _print_exc handle that I had tested. It is possible to override the name and get most of the desired behaviour but there are problems. The following code is from threading.__bootstrap() _print_exc(file=s) _sys.stderr.write("Exception in thread %s:\n%s\n" % (self.getName(), s.getvalue())) This still generates some output to standard error which is not desireable. It is also a global setting which is not what you implied. Your statement is that "each thread has a hook" is certainly not apparent. in the code. This API is also different than what is available globally in the sys module.except() hook. I also checked the cgitb.py module and it also does't handle threads, apparently. I realize that there are other ways to handle intercepting and formatting excetpion output but the callback scheme was so nice. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 11:50 Message: Logged In: YES user_id=21627 Each thread has its own except hook, so you have to set it for each thread. If it is set in a thread, it is also used there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618633&group_id=5470 From noreply@sourceforge.net Sat Oct 5 22:07:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 14:07:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 18:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 23:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 15:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 11:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Sun Oct 6 00:51:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Oct 2002 16:51:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-05 23:51 Message: Logged In: YES user_id=4771 Hunting all overflow bugs seems like a long-term project :-) I can got along the source and submit patches as I find them, but at some point we will need a policy, like a common set of overflow-checking macros to compute the size of the memory to allocate or resize. Just for the fun, a couple more bugs: >>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 21:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 13:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 09:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Sun Oct 6 10:31:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 02:31:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-616019 ] list(xrange(sys.maxint / 4)) -> swapping Message-ID: Bugs item #616019, was opened at 2002-09-29 02:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint / 4)) -> swapping Initial Comment: Refer to #556025 list(xrange(1e9)) --> seg fault for the history. The test in test/test_b1.py causes OS X 10.2.1 to start swapping instantly and never stopped until I killed the process after 5 minutes. I wasn't brave enough to let it run for any longer. list(xrange(1e09)) or even list(xrange(sys.maxint)) works: Traceback (most recent call last): File "test_b1.py", line 553, in ? list(xrange(sys.maxint)) MemoryError PhysMem: 55.7M wired, 300M active, 150M inactive, 506M used, 6.19M free VM: 4.19G + 76.9M 36909(35) pageins, 1505603(200) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1157 python 9.1% 0:33.72 1 13 1186 373M+ 1.55M 160M- 2.29G+ ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2002-10-06 09:31 Message: Logged In: YES user_id=17671 I did a little more digging on this problem. I don't understand why this is happening yet, but I also think I found a bug in obmalloc.c I built a debug interpreter with PYMALLOC_DEBUG after I ran test_b1.py in gdb and saw memset being called with a bogus argument: #1 0x0009722c in _PyObject_DebugMalloc (nbytes=2147483648) at Objects/obmalloc.c:998 nbytes here should be sys.maxint / 4 + 16, but instead memset is being called with sys.maxint + 16. obmalloc.c line 981: total = nbytes + 16 if (total < nbytes || (total >> 31) > 1) { .... return NULL total is a uchar and nbytes is a size_t. Neither side of this test is true if total = sys.maxint + 16 has overflowed: total: 2147483664 nbytes: -2147483632 It seems to me the test should be: if (total < nbytes || (total >> 31) >= 1) { Changing obmalloc.c as above, fixes the swapping, but brings me no closer to finding the actual cause of the poblem. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-01 04:30 Message: Logged In: YES user_id=17671 OK, I added a fprintf to the NRESIZE macro and got the same results on three different platforms, but both OS X builds start swapping rather than raising a MemoryError. I guess the next place to look is PyMem_RESIZE Windows-XP-5.1.2600-SP1: Linux (glibc2.1.3): OS X 10.2.1 (gcc3): OS X 10.2.1 (gcc 2.95.2): sys.maxint: 2147483647 test_b1.py: list _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 536870912 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 16:01 Message: Logged In: YES user_id=21627 Can you please find out how much memory it tries to allocate? The easiest approach might be add a print statement; I *think* the relevant allocation should come from the NRESIZE macro - we'd need to find out what value _new_size has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 From noreply@sourceforge.net Sun Oct 6 12:48:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 04:48:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-618615 ] thread_pthread:undefined ref to sem_post Message-ID: Bugs item #618615, was opened at 2002-10-04 17:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618615&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Martin v. Löwis (loewis) Summary: thread_pthread:undefined ref to sem_post Initial Comment: On Solaris 2.6, thread_pthread.h:412: undefined reference to 'sem_post' gcc version 2.95.2 19991024 (release) ar cr libpython2.3.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/symtablemodule.o Modules/xxsubtype.o ranlib libpython2.3.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.3.a -lsocket -lnsl -ldl -lpthread -lm libpython2.3.a(thread.o): In function `PyThread_allocate_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:334: undefined reference to `sem_init' libpython2.3.a(thread.o): In function `PyThread_free_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:358: undefined reference to `sem_destroy' libpython2.3.a(thread.o): In function `PyThread_acquire_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:387: undefined reference to `sem_wait' /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:389: undefined reference to `sem_trywait' libpython2.3.a(thread.o): In function `PyThread_release_lock': /export/home/jbauer/CVSPython/python/dist/src/Python/thread_pthread.h:412: undefined reference to `sem_post' collect2: ld returned 1 exit status make: *** [python] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-06 13:48 Message: Logged In: YES user_id=21627 Fixed with configure.in 1.352; configure 1.341; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618615&group_id=5470 From noreply@sourceforge.net Sun Oct 6 13:22:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 05:22:50 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-619222 ] os.listdir-alike that includes file type Message-ID: Feature Requests item #619222, was opened at 2002-10-06 05:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir-alike that includes file type Initial Comment: I propose to add two new functions, say os.listdirtypes and os.llistdirtypes. These would be similar to os.listdir except they would return a list of tuples (filename, filetype). This would have the advantage that on oses that support the d_type entry in the dirent struct the type could be calculated without extra calls and harddrive reading. Even on non-supporting os/filesystems, it could emulate it with a call to stat/lstat in the func, still saving some work of calling stat and interpreting its result in python code or using os.path.isX. Filetype would indicate wether the entry was a file, directory, link, fifo, etc. This could either be a char (like ls -l gives) ('-', 'd', 'l', 'p', etc), or some sort of constant (os.DT_REG, os.DT_DIR, os.DT_LNK, os.DT_FIFO, etc). Personally I think the string method is simpler and easier, though some (non-*ix) people may be confused by '-' being file rather than 'f'. (Of course, you could change that, but then *ix users would be confused ;) listdirtypes would be equivalent to using stat, ie. symlinks would be followed when determining types, and llistdirtypes would be like lstat so symlinks would be indicated as 'l'. An app I'm working on right now that reads in a directory tree on startup got about a 2.2x speedup when I implemented this as an extension module, and about 1.6x speedup when I tested it without d_type support. (The module was written using Pyrex, so its not a candidate for inclusion itself, but I would be willing to work on a C implementation if this idea is accepted..) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470 From noreply@sourceforge.net Sun Oct 6 15:14:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 07:14:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-619245 ] PythonLauncher Dialogs do not work Message-ID: Bugs item #619245, was opened at 2002-10-06 14:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Bedford (billbedford) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher Dialogs do not work Initial Comment: While converting some scripts to Python 2.3a using PythonLauncher, I find that if the script opens a dialog, the dialog can not receive mouse clicks. The only way to dismiss the dialog is the quit the Terminal. There is some functionality in the open file dialogs in that you can select a file, but none of the other controls work. Python 2.3a OS X 10.1.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 From noreply@sourceforge.net Sun Oct 6 17:37:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 09:37:58 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-590115 ] please add list.stable_sort() Message-ID: Feature Requests item #590115, was opened at 2002-08-02 08:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=590115&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Nobody/Anonymous (nobody) Summary: please add list.stable_sort() Initial Comment: Now that we have a default stable list.sort() algorithm in the CVS it would be very nice to guarantee some stable-sorting for future (i.e. post 2.3) Python versions. I therefore propose the addtion of a list method stable_sort(). The motivation behind this is that I fear that sooner or later Tim will find yet another major improvement in the sort implementation that might no longer provide stability Currently, doing stable sorting "by hand" typically involves using tuples with added index fields as keys, which is more than suboptimal w.r.t perfomance, memory and code cleanless. Markus ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer (mfx) Date: 2002-09-13 07:40 Message: Logged In: YES user_id=12151 Please close this request - it's superseded by my python-stablesort package. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-02 20:19 Message: Logged In: YES user_id=31435 Noting that Guido already rejected this idea. Note that the word "stable" appears in the docstring for list.sort() in 2.3, but not before, so it's easy to check . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=590115&group_id=5470 From noreply@sourceforge.net Sun Oct 6 22:56:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 14:56:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-619400 ] test_builtin hangs on MacOSX 10.2.1 Message-ID: Bugs item #619400, was opened at 2002-10-06 23:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619400&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_builtin hangs on MacOSX 10.2.1 Initial Comment: Test_builtin appears to hang on Mac OS X 10.2.1, in the 'list' section. Actually, if you are low on swapspace (or, equivalently, on freespace on your system drive) it may hang your whole system. Python cannot be interrupted (control-c) at this moment, but I'm sometimes able to control-z and kill. My guess right now is that 10.2.1 overcommits memory and that this somehow hangs Python. I have never seen this problem on 10.1.X or 10.2, but I will investigate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619400&group_id=5470 From noreply@sourceforge.net Sun Oct 6 22:59:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 14:59:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-619245 ] PythonLauncher Dialogs do not work Message-ID: Bugs item #619245, was opened at 2002-10-06 16:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Bedford (billbedford) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher Dialogs do not work Initial Comment: While converting some scripts to Python 2.3a using PythonLauncher, I find that if the script opens a dialog, the dialog can not receive mouse clicks. The only way to dismiss the dialog is the quit the Terminal. There is some functionality in the open file dialogs in that you can select a file, but none of the other controls work. Python 2.3a OS X 10.1.5 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-10-06 23:59 Message: Logged In: YES user_id=45365 Bill, I think there's a misunderstanding here. Are you using PythonLauncher from the terminal? It isn't intended to be used as such, for that you should use "pythonw". If this is the problem let me know (it can probably be fixed, or PythonLauncher should complain). If it isn't what you're doing please give me a recipe to repeat this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 From noreply@sourceforge.net Mon Oct 7 07:29:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 23:29:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-619400 ] test_builtin hangs on MacOSX 10.2.1 Message-ID: Bugs item #619400, was opened at 2002-10-06 23:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619400&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_builtin hangs on MacOSX 10.2.1 Initial Comment: Test_builtin appears to hang on Mac OS X 10.2.1, in the 'list' section. Actually, if you are low on swapspace (or, equivalently, on freespace on your system drive) it may hang your whole system. Python cannot be interrupted (control-c) at this moment, but I'm sometimes able to control-z and kill. My guess right now is that 10.2.1 overcommits memory and that this somehow hangs Python. I have never seen this problem on 10.1.X or 10.2, but I will investigate. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 08:29 Message: Logged In: YES user_id=21627 I think this is a duplicate of # 616019. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619400&group_id=5470 From noreply@sourceforge.net Mon Oct 7 07:39:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 23:39:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-618594 ] Connecting to IPv4 addrs from IPv6 socke Message-ID: Bugs item #618594, was opened at 2002-10-04 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting to IPv4 addrs from IPv6 socke Initial Comment: You can connect to a IPv4 addr "a.b.c.d" from a IPv6 socket simply connecting to "::FFFF:a.b.c.d" IPv6 address. When you issue a "connect" call on a IPv6 socket using a pure IPv4 addr "a.b.c.d", this format SHOULD be converted "automagically" to "::FFFF:a.b.c.d", intenally. Currently, this operation gives an error. The real problem is "connect" call using a hostname (not resolved to a IPv4 or IPv6 addr). Since I don't know to which IP address type the host will resolve, I think the correct course should be to promote IPv4 to IPv6 address space (if the socket is IPv6) and to connect normally. Obviously, trying to connect to a IPv6 addr using a IPv4 socket should fail, like just now. When a hostname used in "connect" call resolves to both IPv4 and IPv6 addresses, it would use IPv4 if the socket is IPv4, and IPv6 if the socket is IPv6. ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-10-07 08:39 Message: Logged In: YES user_id=97460 The problem, as I said, is when you use a hostname in the "connect" call. Since the program has no control over the address type the DNS lookup will resolve, I, in my soft, can't search for colons in order to create IF_INET or IF_INET6 sockets, since that info is processed inside the "connect" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 12:11 Message: Logged In: YES user_id=21627 I fail to see a Python bug here. All calls are delegated to the C library, which delegates most of it to the kernel. So complain to your operating system vendor. I don't think your complaint is valid, though: the sockaddr is computed by looking at its format. If it does not contains a colon, it is not an AF_INET6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 From noreply@sourceforge.net Mon Oct 7 07:46:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 06 Oct 2002 23:46:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-618594 ] Connecting to IPv4 addrs from IPv6 socke Message-ID: Bugs item #618594, was opened at 2002-10-04 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting to IPv4 addrs from IPv6 socke Initial Comment: You can connect to a IPv4 addr "a.b.c.d" from a IPv6 socket simply connecting to "::FFFF:a.b.c.d" IPv6 address. When you issue a "connect" call on a IPv6 socket using a pure IPv4 addr "a.b.c.d", this format SHOULD be converted "automagically" to "::FFFF:a.b.c.d", intenally. Currently, this operation gives an error. The real problem is "connect" call using a hostname (not resolved to a IPv4 or IPv6 addr). Since I don't know to which IP address type the host will resolve, I think the correct course should be to promote IPv4 to IPv6 address space (if the socket is IPv6) and to connect normally. Obviously, trying to connect to a IPv6 addr using a IPv4 socket should fail, like just now. When a hostname used in "connect" call resolves to both IPv4 and IPv6 addresses, it would use IPv4 if the socket is IPv4, and IPv6 if the socket is IPv6. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 08:46 Message: Logged In: YES user_id=21627 Can you please post an example connect call? Did you consider the IPv6 example in http://www.python.org/doc/current/lib/socket-example.html ? ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-10-07 08:39 Message: Logged In: YES user_id=97460 The problem, as I said, is when you use a hostname in the "connect" call. Since the program has no control over the address type the DNS lookup will resolve, I, in my soft, can't search for colons in order to create IF_INET or IF_INET6 sockets, since that info is processed inside the "connect" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 12:11 Message: Logged In: YES user_id=21627 I fail to see a Python bug here. All calls are delegated to the C library, which delegates most of it to the kernel. So complain to your operating system vendor. I don't think your complaint is valid, though: the sockaddr is computed by looking at its format. If it does not contains a colon, it is not an AF_INET6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 From noreply@sourceforge.net Mon Oct 7 09:09:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 01:09:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-618594 ] Connecting to IPv4 addrs from IPv6 socke Message-ID: Bugs item #618594, was opened at 2002-10-04 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting to IPv4 addrs from IPv6 socke Initial Comment: You can connect to a IPv4 addr "a.b.c.d" from a IPv6 socket simply connecting to "::FFFF:a.b.c.d" IPv6 address. When you issue a "connect" call on a IPv6 socket using a pure IPv4 addr "a.b.c.d", this format SHOULD be converted "automagically" to "::FFFF:a.b.c.d", intenally. Currently, this operation gives an error. The real problem is "connect" call using a hostname (not resolved to a IPv4 or IPv6 addr). Since I don't know to which IP address type the host will resolve, I think the correct course should be to promote IPv4 to IPv6 address space (if the socket is IPv6) and to connect normally. Obviously, trying to connect to a IPv6 addr using a IPv4 socket should fail, like just now. When a hostname used in "connect" call resolves to both IPv4 and IPv6 addresses, it would use IPv4 if the socket is IPv4, and IPv6 if the socket is IPv6. ---------------------------------------------------------------------- >Comment By: Jesús Cea Avión (jcea) Date: 2002-10-07 10:09 Message: Logged In: YES user_id=97460 >>> import socket >>> a=socket.socket(socket.AF_INET6,socket.SOCK_STREAM) >>> a.connect(("www.elmundo.es",80)) If "www.elmundo.es" is a IPv4 ONLY server, the connect "fails". Nevertheless, you can reach IPv4 hosts from IPv6 sockets, using the "::FFFF:a.b.c.d" format... You suggest using "getaddinfo". That could be an option but, then, this problem should be documented in docs, I think :-p ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 08:46 Message: Logged In: YES user_id=21627 Can you please post an example connect call? Did you consider the IPv6 example in http://www.python.org/doc/current/lib/socket-example.html ? ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-10-07 08:39 Message: Logged In: YES user_id=97460 The problem, as I said, is when you use a hostname in the "connect" call. Since the program has no control over the address type the DNS lookup will resolve, I, in my soft, can't search for colons in order to create IF_INET or IF_INET6 sockets, since that info is processed inside the "connect" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 12:11 Message: Logged In: YES user_id=21627 I fail to see a Python bug here. All calls are delegated to the C library, which delegates most of it to the kernel. So complain to your operating system vendor. I don't think your complaint is valid, though: the sockaddr is computed by looking at its format. If it does not contains a colon, it is not an AF_INET6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:02:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:02:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-618594 ] Connecting to IPv4 addrs from IPv6 socke Message-ID: Bugs item #618594, was opened at 2002-10-04 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 Category: Extension Modules Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting to IPv4 addrs from IPv6 socke Initial Comment: You can connect to a IPv4 addr "a.b.c.d" from a IPv6 socket simply connecting to "::FFFF:a.b.c.d" IPv6 address. When you issue a "connect" call on a IPv6 socket using a pure IPv4 addr "a.b.c.d", this format SHOULD be converted "automagically" to "::FFFF:a.b.c.d", intenally. Currently, this operation gives an error. The real problem is "connect" call using a hostname (not resolved to a IPv4 or IPv6 addr). Since I don't know to which IP address type the host will resolve, I think the correct course should be to promote IPv4 to IPv6 address space (if the socket is IPv6) and to connect normally. Obviously, trying to connect to a IPv6 addr using a IPv4 socket should fail, like just now. When a hostname used in "connect" call resolves to both IPv4 and IPv6 addresses, it would use IPv4 if the socket is IPv4, and IPv6 if the socket is IPv6. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 13:02 Message: Logged In: YES user_id=21627 Please understand that we expose the functionality from the C library. If you do socket.getaddrinfo("www.elmundo.es",None,0,socket.SOCK_STREAM) you get [(2, 1, 6, '', ('193.110.128.200', 0))] i.e. there is *no* IPv4 mapped address reported from the C library. See http://www.wcug.wwu.edu/lists/netdev/199702/msg00179.html why there is no need to report one, and http://lwn.net/Articles/8646/ why IPv4 mapped addresses are considered harmful. See the examples of how to use getaddrinfo to solve this problem: getaddrinfo tells you to open a IPv4 socket if there is no IPv6 connectivity to the requested service. I see no need to change any documentation. If you think something should change, please submit a patch. ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-10-07 10:09 Message: Logged In: YES user_id=97460 >>> import socket >>> a=socket.socket(socket.AF_INET6,socket.SOCK_STREAM) >>> a.connect(("www.elmundo.es",80)) If "www.elmundo.es" is a IPv4 ONLY server, the connect "fails". Nevertheless, you can reach IPv4 hosts from IPv6 sockets, using the "::FFFF:a.b.c.d" format... You suggest using "getaddinfo". That could be an option but, then, this problem should be documented in docs, I think :-p ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 08:46 Message: Logged In: YES user_id=21627 Can you please post an example connect call? Did you consider the IPv6 example in http://www.python.org/doc/current/lib/socket-example.html ? ---------------------------------------------------------------------- Comment By: Jesús Cea Avión (jcea) Date: 2002-10-07 08:39 Message: Logged In: YES user_id=97460 The problem, as I said, is when you use a hostname in the "connect" call. Since the program has no control over the address type the DNS lookup will resolve, I, in my soft, can't search for colons in order to create IF_INET or IF_INET6 sockets, since that info is processed inside the "connect" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 12:11 Message: Logged In: YES user_id=21627 I fail to see a Python bug here. All calls are delegated to the C library, which delegates most of it to the kernel. So complain to your operating system vendor. I don't think your complaint is valid, though: the sockaddr is computed by looking at its format. If it does not contains a colon, it is not an AF_INET6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618594&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:20:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:20:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result Message-ID: Bugs item #593581, was opened at 2002-08-11 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 Category: Unicode Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: M.-A. Lemburg (lemburg) Summary: u'%c' % large value: broken result Initial Comment: The unicode implementation of '%c' % x does no range checking on x, and out-of-range values can cause weird effects. You might want to implement the same range checking as 8-bit strings use, restricting x to values in range(256). Or you might want to implement unichr(x), restricting x to values in range(0xffff). But right now it's a mess: >>> u'%c' % 100 u'd' >>> u'%c' % 300 u',' >>> u'%c' % 900 u'\uff84' >>> u'%c' % -900 u'|' >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:20 Message: Logged In: YES user_id=6656 Maybe this is a dead horse already... 2.2.2 candidate? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-08-11 12:23 Message: Logged In: YES user_id=38388 Fix checked in. u"%c" will now apply the same checks as unichr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:44:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:44:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result Message-ID: Bugs item #593581, was opened at 2002-08-11 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 Category: Unicode Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: M.-A. Lemburg (lemburg) Summary: u'%c' % large value: broken result Initial Comment: The unicode implementation of '%c' % x does no range checking on x, and out-of-range values can cause weird effects. You might want to implement the same range checking as 8-bit strings use, restricting x to values in range(256). Or you might want to implement unichr(x), restricting x to values in range(0xffff). But right now it's a mess: >>> u'%c' % 100 u'd' >>> u'%c' % 300 u',' >>> u'%c' % 900 u'\uff84' >>> u'%c' % -900 u'|' >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:44 Message: Logged In: YES user_id=38388 I agree: this is a 2.2.2 candidate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:20 Message: Logged In: YES user_id=6656 Maybe this is a dead horse already... 2.2.2 candidate? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-08-11 12:23 Message: Logged In: YES user_id=38388 Fix checked in. u"%c" will now apply the same checks as unichr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:48:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:48:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result Message-ID: Bugs item #593581, was opened at 2002-08-11 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 Category: Unicode Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: M.-A. Lemburg (lemburg) Summary: u'%c' % large value: broken result Initial Comment: The unicode implementation of '%c' % x does no range checking on x, and out-of-range values can cause weird effects. You might want to implement the same range checking as 8-bit strings use, restricting x to values in range(256). Or you might want to implement unichr(x), restricting x to values in range(0xffff). But right now it's a mess: >>> u'%c' % 100 u'd' >>> u'%c' % 300 u',' >>> u'%c' % 900 u'\uff84' >>> u'%c' % -900 u'|' >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:48 Message: Logged In: YES user_id=6656 My word, it applied to release22-maint without conflicting! This hasn't happened to me very much of late. It was just changes to unicodeobject.c and test_unicode.py, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:44 Message: Logged In: YES user_id=38388 I agree: this is a 2.2.2 candidate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:20 Message: Logged In: YES user_id=6656 Maybe this is a dead horse already... 2.2.2 candidate? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-08-11 12:23 Message: Logged In: YES user_id=38388 Fix checked in. u"%c" will now apply the same checks as unichr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:52:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:52:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result Message-ID: Bugs item #593581, was opened at 2002-08-11 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 Category: Unicode Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: M.-A. Lemburg (lemburg) Summary: u'%c' % large value: broken result Initial Comment: The unicode implementation of '%c' % x does no range checking on x, and out-of-range values can cause weird effects. You might want to implement the same range checking as 8-bit strings use, restricting x to values in range(256). Or you might want to implement unichr(x), restricting x to values in range(0xffff). But right now it's a mess: >>> u'%c' % 100 u'd' >>> u'%c' % 300 u',' >>> u'%c' % 900 u'\uff84' >>> u'%c' % -900 u'|' >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:52 Message: Logged In: YES user_id=6656 Well, I can answer part of that question: no, there's bltinmodule.c and unicodeobject.h too. Sometimes I hate cvs... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:48 Message: Logged In: YES user_id=6656 My word, it applied to release22-maint without conflicting! This hasn't happened to me very much of late. It was just changes to unicodeobject.c and test_unicode.py, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:44 Message: Logged In: YES user_id=38388 I agree: this is a 2.2.2 candidate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:20 Message: Logged In: YES user_id=6656 Maybe this is a dead horse already... 2.2.2 candidate? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-08-11 12:23 Message: Logged In: YES user_id=38388 Fix checked in. u"%c" will now apply the same checks as unichr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 From noreply@sourceforge.net Mon Oct 7 12:57:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 04:57:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result Message-ID: Bugs item #593581, was opened at 2002-08-11 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 Category: Unicode Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: M.-A. Lemburg (lemburg) Summary: u'%c' % large value: broken result Initial Comment: The unicode implementation of '%c' % x does no range checking on x, and out-of-range values can cause weird effects. You might want to implement the same range checking as 8-bit strings use, restricting x to values in range(256). Or you might want to implement unichr(x), restricting x to values in range(0xffff). But right now it's a mess: >>> u'%c' % 100 u'd' >>> u'%c' % 300 u',' >>> u'%c' % 900 u'\uff84' >>> u'%c' % -900 u'|' >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:57 Message: Logged In: YES user_id=38388 You found the answer yourself :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:52 Message: Logged In: YES user_id=6656 Well, I can answer part of that question: no, there's bltinmodule.c and unicodeobject.h too. Sometimes I hate cvs... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:48 Message: Logged In: YES user_id=6656 My word, it applied to release22-maint without conflicting! This hasn't happened to me very much of late. It was just changes to unicodeobject.c and test_unicode.py, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:44 Message: Logged In: YES user_id=38388 I agree: this is a 2.2.2 candidate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:20 Message: Logged In: YES user_id=6656 Maybe this is a dead horse already... 2.2.2 candidate? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-08-11 12:23 Message: Logged In: YES user_id=38388 Fix checked in. u"%c" will now apply the same checks as unichr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 From noreply@sourceforge.net Mon Oct 7 13:34:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 05:34:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-593581 ] u'%c' % large value: broken result Message-ID: Bugs item #593581, was opened at 2002-08-11 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 Category: Unicode Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: M.-A. Lemburg (lemburg) Summary: u'%c' % large value: broken result Initial Comment: The unicode implementation of '%c' % x does no range checking on x, and out-of-range values can cause weird effects. You might want to implement the same range checking as 8-bit strings use, restricting x to values in range(256). Or you might want to implement unichr(x), restricting x to values in range(0xffff). But right now it's a mess: >>> u'%c' % 100 u'd' >>> u'%c' % 300 u',' >>> u'%c' % 900 u'\uff84' >>> u'%c' % -900 u'|' >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-07 12:34 Message: Logged In: YES user_id=6656 There was Misc/NEWS too (logmerge.py to the rescue!). Anyway, this is fixed on the branch. I'd close the bug, only I never got round to reopening it... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:57 Message: Logged In: YES user_id=38388 You found the answer yourself :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:52 Message: Logged In: YES user_id=6656 Well, I can answer part of that question: no, there's bltinmodule.c and unicodeobject.h too. Sometimes I hate cvs... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:48 Message: Logged In: YES user_id=6656 My word, it applied to release22-maint without conflicting! This hasn't happened to me very much of late. It was just changes to unicodeobject.c and test_unicode.py, right? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-07 11:44 Message: Logged In: YES user_id=38388 I agree: this is a 2.2.2 candidate. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-07 11:20 Message: Logged In: YES user_id=6656 Maybe this is a dead horse already... 2.2.2 candidate? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-08-11 12:23 Message: Logged In: YES user_id=38388 Fix checked in. u"%c" will now apply the same checks as unichr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=593581&group_id=5470 From noreply@sourceforge.net Mon Oct 7 15:15:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 07:15:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 10:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 From noreply@sourceforge.net Mon Oct 7 15:41:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 07:41:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-610730 ] Numpy doesn't build for Python.framework Message-ID: Bugs item #610730, was opened at 2002-09-17 21:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610730&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: Numpy doesn't build for Python.framework Initial Comment: Running "python setup.py build" in a recent Numeric folder ends with this error: building 'umath' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long- double -no-cpp-precomp -fno-common -dynamic -DHAVE_INVERSE_HYPERBOLIC - IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c Src/umathmodule.c -o build/temp.darwin-5.5-Power Macintosh-2.3/ umathmodule.o Src/umathmodule.c: In function `UINT_multiply': Src/umathmodule.c:718: warning: `x' might be used uninitialized in this function Src/umathmodule.c: At top level: Src/umathmodule.c:2394: `acosh' undeclared here (not in a function) Src/umathmodule.c:2394: too many errors, bailing out error: command 'gcc' failed with exit status 1 [python:~/code/Numeric-22.0] just% Seth Delackner reports: """I had this *exact* same problem until I nuked my old /usr/local/bin/python* and reinstalled from 2.2.1's release source.tar.gz, following letter for letter the instructions in the Mac/OSX/README file. Thing to remember is that installing the framework build does NOT create simlinks in /usr/local/bin, so old versions of python sitting there can screw it all up.""" I am not willing to do this until Python.framework is fully working, so I can't verify this workaround... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-10-07 16:41 Message: Logged In: YES user_id=45365 Rob Managhan posted the following suggestion on pythonmac-sig, could you please try it? Set and I were having problems compiling the Python Numeric module for OSX 10.1.5 sue to missing inverse hyperbolic functions. I added these lines to setup.py (the first two are already there) elif sys.platform in ['mac', 'beos5']: mathlibs = [] elif sys.platform in ['darwin']: undef_macros = ['HAVE_INVERSE_HYPERBOLIC'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610730&group_id=5470 From noreply@sourceforge.net Mon Oct 7 15:53:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 07:53:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-07 09:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Mon Oct 7 18:15:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 10:15:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerson Kurz (gersonkurz) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Mon Oct 7 19:09:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 11:09:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-537450 ] Improper object initialization Message-ID: Bugs item #537450, was opened at 2002-03-31 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kevin Jacobs (jacobs99) Assigned to: Guido van Rossum (gvanrossum) Summary: Improper object initialization Initial Comment: The descr tutorial specifies this rule: __new__ must return an object. There's nothing that requires that it return a new object that is an instance of its class argument, although that is the convention. If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called. I believe that this rule adds an unnecessary wart to the language, since it is not appropriate to call __init__, especially with the same arguments as __new__ on an 'unexpected' class returned by __new__. It is simple enough to check that the resulting class is an instance of the expected class and to only then call __init__. Otherwise, it should be assumed that __new__ is returning a fully constructed instance of another class. In the rare and obscure case that one does wish to call __init__ on an object of a different class, then it may be done manually from within __new__. So basically, my argument is for explicit versus implicit semantics. If __new__(cls) returns an instance where type(instance) is not cls, then __init__ should not be called implicitly. The burden should be on the programmer to explicitly ensure that the object is properly constructed. Here is an example where the current rule results in confusing and apparently random behavior (if one doesn't have initimate knowledge of the Python implementation, that is): class Foo(object): def __new__(cls, x): if x == 0: return [1,2,3] if x == 1: return 1 if x == 2: return (1,2,3) if x == 3: return '1' if x == 4: return {1:1,2:2,3:3} else: return super(cls, Foo).__new__(cls) for i in range(6): try: print 'Foo(%d) =' % i,Foo(i) except: print 'Foo(%d) failed' % i Which under Python 2.2 results in the following output: Foo(0) failed Foo(1) = 1 Foo(2) = (1, 2, 3) Foo(3) = 1 Foo(4) failed Foo(5) = <__main__.Foo object at 0x8147f54> Under the proposed new rule, the output would be much more sensible: Foo(0) = [1,2,3] Foo(1) = 1 Foo(2) = (1, 2, 3) Foo(3) = 1 Foo(4) = {1:1,2:2,3:3} Foo(5) = <__main__.Foo object at 0x8147f54> If there is agreement on this issue, I will submit a very simple patch to address this. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-07 14:09 Message: Logged In: YES user_id=6380 Given Kevin's plea, I've backported this to Python 2.2.2b1, with the caveat that I may undo it if problems arise during the (short!) beta release time. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 20:05 Message: Logged In: YES user_id=6380 Fixed in CVS, using PyType_IsSubtype(obj->type, type). Note that the exception for type(x) is still needed (the test suite could have told you that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 19:17 Message: Logged In: YES user_id=6380 I think Kevin's suggestion is about right, but I'd like to add one twist: C.__new__ could return an instance of a subclass of C, and in that case I think that the __init__ should still be called. I'll see about a proper fix. It's a clear semantic change, so I don't want to change this in 2.2.x. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-01 09:43 Message: Logged In: YES user_id=31435 Thanks, Kevin! Assigned to Guido, under the theory that it lands on his plate sooner or later, and better sooner. ---------------------------------------------------------------------- Comment By: Kevin Jacobs (jacobs99) Date: 2002-04-01 09:17 Message: Logged In: YES user_id=459565 Patch attached. Passes Python descr tests and our extremely comprehensive in-house test suite that tortures new-style classes in fairly gruesome ways. Note: The ugly test to avoid calling tp_init on type(x) calls was intentionally left in the code, to handle the case of calling type(type). It is very likely that the test is now unnecessary and can be removed since calling tp_init on type objects should be safe, because they do not implement their own tp_init. However, for the sake of simplicity, I'm going to leave this additional cleanup to Guido, or others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470 From noreply@sourceforge.net Mon Oct 7 20:10:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 12:10:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-619843 ] readline broken in configure Message-ID: Bugs item #619843, was opened at 2002-10-07 14:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619843&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: readline broken in configure Initial Comment: It appears that support for readline broke on my machine between 2.2.1 and 2.3a. Pasted below is a relevant section from config.log. configure:15640: checking for rl_pre_input_hook in -lreadline configure:15673: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -lsocket -lnsl -lposix4 -ldl -lpthread >&5 configure:15676: $? = 0 configure:15679: test -s conftest configure:15682: $? = 0 configure:15693: result: yes configure:15705: checking for rl_completion_matches in -lreadline configure:15738: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -lsocket -lnsl -lposix4 -ldl -lpthread >&5 /var/tmp/ccoJe7u1.o: In function `main': /export/home/jbauer/CVSPython/python/dist/src/configure:15730: undefined referen ce to `rl_completion_matches' collect2: ld returned 1 exit status configure:15741: $? = 1 configure: failed program was: #line 15712 "configure" #include "confdefs.h" [My setup: Sparc Solaris 2.6, readline 4.2] I cut and pasted the relevant section from my old 2.2.1 configure file and readline is now working again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619843&group_id=5470 From noreply@sourceforge.net Mon Oct 7 20:34:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 12:34:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-619843 ] readline broken in configure Message-ID: Bugs item #619843, was opened at 2002-10-07 21:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619843&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: readline broken in configure Initial Comment: It appears that support for readline broke on my machine between 2.2.1 and 2.3a. Pasted below is a relevant section from config.log. configure:15640: checking for rl_pre_input_hook in -lreadline configure:15673: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -lsocket -lnsl -lposix4 -ldl -lpthread >&5 configure:15676: $? = 0 configure:15679: test -s conftest configure:15682: $? = 0 configure:15693: result: yes configure:15705: checking for rl_completion_matches in -lreadline configure:15738: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -lsocket -lnsl -lposix4 -ldl -lpthread >&5 /var/tmp/ccoJe7u1.o: In function `main': /export/home/jbauer/CVSPython/python/dist/src/configure:15730: undefined referen ce to `rl_completion_matches' collect2: ld returned 1 exit status configure:15741: $? = 1 configure: failed program was: #line 15712 "configure" #include "confdefs.h" [My setup: Sparc Solaris 2.6, readline 4.2] I cut and pasted the relevant section from my old 2.2.1 configure file and readline is now working again. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 21:34 Message: Logged In: YES user_id=21627 Why do you think that support for readline broke? The test have completed as designed: rl_pre_input_hook is present in your version of readline, rl_completion_matches is not, so you have readline 4.0 (or 4.1). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619843&group_id=5470 From noreply@sourceforge.net Mon Oct 7 20:36:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 12:36:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-07 16:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) >Assigned to: Piers Lauder (pierslauder) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Mon Oct 7 21:45:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 13:45:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-619843 ] readline broken in configure Message-ID: Bugs item #619843, was opened at 2002-10-07 14:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619843&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: readline broken in configure Initial Comment: It appears that support for readline broke on my machine between 2.2.1 and 2.3a. Pasted below is a relevant section from config.log. configure:15640: checking for rl_pre_input_hook in -lreadline configure:15673: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -lsocket -lnsl -lposix4 -ldl -lpthread >&5 configure:15676: $? = 0 configure:15679: test -s conftest configure:15682: $? = 0 configure:15693: result: yes configure:15705: checking for rl_completion_matches in -lreadline configure:15738: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -lsocket -lnsl -lposix4 -ldl -lpthread >&5 /var/tmp/ccoJe7u1.o: In function `main': /export/home/jbauer/CVSPython/python/dist/src/configure:15730: undefined referen ce to `rl_completion_matches' collect2: ld returned 1 exit status configure:15741: $? = 1 configure: failed program was: #line 15712 "configure" #include "confdefs.h" [My setup: Sparc Solaris 2.6, readline 4.2] I cut and pasted the relevant section from my old 2.2.1 configure file and readline is now working again. ---------------------------------------------------------------------- >Comment By: Jeff Bauer (jeffbauer) Date: 2002-10-07 15:45 Message: Logged In: YES user_id=458828 Perhaps I had a misconfigured readline installation. I downloaded a fresh copy and reinstalled it. It's now working with Python2.3. I'll close this bug report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 14:34 Message: Logged In: YES user_id=21627 Why do you think that support for readline broke? The test have completed as designed: rl_pre_input_hook is present in your version of readline, rl_completion_matches is not, so you have readline 4.0 (or 4.1). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619843&group_id=5470 From noreply@sourceforge.net Mon Oct 7 22:53:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 14:53:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 10:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- >Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-07 17:53 Message: Logged In: YES user_id=271417 I should have noted that 'import' _does_ work to a degree - 'import os' worked. The '_example.dll' that I am trying to import is the 'shapes' example that is distributed with SWIG 1.3.15, and should import without any trouble. It does import just fine from the command line version of Python, but not from Idle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 From noreply@sourceforge.net Mon Oct 7 23:29:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 15:29:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-616019 ] list(xrange(sys.maxint / 4)) -> swapping Message-ID: Bugs item #616019, was opened at 2002-09-29 02:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint / 4)) -> swapping Initial Comment: Refer to #556025 list(xrange(1e9)) --> seg fault for the history. The test in test/test_b1.py causes OS X 10.2.1 to start swapping instantly and never stopped until I killed the process after 5 minutes. I wasn't brave enough to let it run for any longer. list(xrange(1e09)) or even list(xrange(sys.maxint)) works: Traceback (most recent call last): File "test_b1.py", line 553, in ? list(xrange(sys.maxint)) MemoryError PhysMem: 55.7M wired, 300M active, 150M inactive, 506M used, 6.19M free VM: 4.19G + 76.9M 36909(35) pageins, 1505603(200) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1157 python 9.1% 0:33.72 1 13 1186 373M+ 1.55M 160M- 2.29G+ ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2002-10-07 22:29 Message: Logged In: YES user_id=17671 Forget what I said in the last comment. I must have been asleep. The problem boils down to this: OS X does lazy memory allocation and each process gets up to 4GB of virtual memory. I now know a lot more about how the interpreter manages memory. I could have saved myself the trouble by paying attention to what the VM: 4.19G+ in top was telling me. The test in test_b1.py should not be run on OS X. I am going to avoid problems like this in the future by setting a hard limit on per process memory of 400MB. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-06 09:31 Message: Logged In: YES user_id=17671 I did a little more digging on this problem. I don't understand why this is happening yet, but I also think I found a bug in obmalloc.c I built a debug interpreter with PYMALLOC_DEBUG after I ran test_b1.py in gdb and saw memset being called with a bogus argument: #1 0x0009722c in _PyObject_DebugMalloc (nbytes=2147483648) at Objects/obmalloc.c:998 nbytes here should be sys.maxint / 4 + 16, but instead memset is being called with sys.maxint + 16. obmalloc.c line 981: total = nbytes + 16 if (total < nbytes || (total >> 31) > 1) { .... return NULL total is a uchar and nbytes is a size_t. Neither side of this test is true if total = sys.maxint + 16 has overflowed: total: 2147483664 nbytes: -2147483632 It seems to me the test should be: if (total < nbytes || (total >> 31) >= 1) { Changing obmalloc.c as above, fixes the swapping, but brings me no closer to finding the actual cause of the poblem. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-01 04:30 Message: Logged In: YES user_id=17671 OK, I added a fprintf to the NRESIZE macro and got the same results on three different platforms, but both OS X builds start swapping rather than raising a MemoryError. I guess the next place to look is PyMem_RESIZE Windows-XP-5.1.2600-SP1: Linux (glibc2.1.3): OS X 10.2.1 (gcc3): OS X 10.2.1 (gcc 2.95.2): sys.maxint: 2147483647 test_b1.py: list _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 536870912 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 16:01 Message: Logged In: YES user_id=21627 Can you please find out how much memory it tries to allocate? The easiest approach might be add a print statement; I *think* the relevant allocation should come from the NRESIZE macro - we'd need to find out what value _new_size has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 From noreply@sourceforge.net Tue Oct 8 00:43:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Oct 2002 16:43:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-610730 ] Numpy doesn't build for Python.framework Message-ID: Bugs item #610730, was opened at 2002-09-17 21:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610730&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: Numpy doesn't build for Python.framework Initial Comment: Running "python setup.py build" in a recent Numeric folder ends with this error: building 'umath' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long- double -no-cpp-precomp -fno-common -dynamic -DHAVE_INVERSE_HYPERBOLIC - IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c Src/umathmodule.c -o build/temp.darwin-5.5-Power Macintosh-2.3/ umathmodule.o Src/umathmodule.c: In function `UINT_multiply': Src/umathmodule.c:718: warning: `x' might be used uninitialized in this function Src/umathmodule.c: At top level: Src/umathmodule.c:2394: `acosh' undeclared here (not in a function) Src/umathmodule.c:2394: too many errors, bailing out error: command 'gcc' failed with exit status 1 [python:~/code/Numeric-22.0] just% Seth Delackner reports: """I had this *exact* same problem until I nuked my old /usr/local/bin/python* and reinstalled from 2.2.1's release source.tar.gz, following letter for letter the instructions in the Mac/OSX/README file. Thing to remember is that installing the framework build does NOT create simlinks in /usr/local/bin, so old versions of python sitting there can screw it all up.""" I am not willing to do this until Python.framework is fully working, so I can't verify this workaround... ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2002-10-08 01:43 Message: Logged In: YES user_id=92689 This does indeed fix the problem for me. Does this mean it's a NumPy bug? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-10-07 16:41 Message: Logged In: YES user_id=45365 Rob Managhan posted the following suggestion on pythonmac-sig, could you please try it? Set and I were having problems compiling the Python Numeric module for OSX 10.1.5 sue to missing inverse hyperbolic functions. I added these lines to setup.py (the first two are already there) elif sys.platform in ['mac', 'beos5']: mathlibs = [] elif sys.platform in ['darwin']: undef_macros = ['HAVE_INVERSE_HYPERBOLIC'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610730&group_id=5470 From noreply@sourceforge.net Tue Oct 8 09:54:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 01:54:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-610730 ] Numpy doesn't build for Python.framework Message-ID: Bugs item #610730, was opened at 2002-09-17 21:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610730&group_id=5470 Category: Macintosh >Group: 3rd Party >Status: Closed Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: Numpy doesn't build for Python.framework Initial Comment: Running "python setup.py build" in a recent Numeric folder ends with this error: building 'umath' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long- double -no-cpp-precomp -fno-common -dynamic -DHAVE_INVERSE_HYPERBOLIC - IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/Library/Frameworks/Python.framework/Versions/2.3/include/ python2.3 -c Src/umathmodule.c -o build/temp.darwin-5.5-Power Macintosh-2.3/ umathmodule.o Src/umathmodule.c: In function `UINT_multiply': Src/umathmodule.c:718: warning: `x' might be used uninitialized in this function Src/umathmodule.c: At top level: Src/umathmodule.c:2394: `acosh' undeclared here (not in a function) Src/umathmodule.c:2394: too many errors, bailing out error: command 'gcc' failed with exit status 1 [python:~/code/Numeric-22.0] just% Seth Delackner reports: """I had this *exact* same problem until I nuked my old /usr/local/bin/python* and reinstalled from 2.2.1's release source.tar.gz, following letter for letter the instructions in the Mac/OSX/README file. Thing to remember is that installing the framework build does NOT create simlinks in /usr/local/bin, so old versions of python sitting there can screw it all up.""" I am not willing to do this until Python.framework is fully working, so I can't verify this workaround... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-10-08 10:54 Message: Logged In: YES user_id=45365 Yes, it's a numpy bug (or, alternatively, a MacOSX bug). MacOSX doesn't cave the hyperbolic functions, so numpy should cater for that. Can you pass the bug on to them, just to be sure? Probably Rob has already done that, but you never know... ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-10-08 01:43 Message: Logged In: YES user_id=92689 This does indeed fix the problem for me. Does this mean it's a NumPy bug? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-10-07 16:41 Message: Logged In: YES user_id=45365 Rob Managhan posted the following suggestion on pythonmac-sig, could you please try it? Set and I were having problems compiling the Python Numeric module for OSX 10.1.5 sue to missing inverse hyperbolic functions. I added these lines to setup.py (the first two are already there) elif sys.platform in ['mac', 'beos5']: mathlibs = [] elif sys.platform in ['darwin']: undef_macros = ['HAVE_INVERSE_HYPERBOLIC'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610730&group_id=5470 From noreply@sourceforge.net Tue Oct 8 10:27:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 02:27:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-619245 ] PythonLauncher Dialogs do not work Message-ID: Bugs item #619245, was opened at 2002-10-06 14:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Bedford (billbedford) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher Dialogs do not work Initial Comment: While converting some scripts to Python 2.3a using PythonLauncher, I find that if the script opens a dialog, the dialog can not receive mouse clicks. The only way to dismiss the dialog is the quit the Terminal. There is some functionality in the open file dialogs in that you can select a file, but none of the other controls work. Python 2.3a OS X 10.1.5 ---------------------------------------------------------------------- >Comment By: Bill Bedford (billbedford) Date: 2002-10-08 09:27 Message: Logged In: YES user_id=624163 Jack You are right I misunderstood the pythonw thing. What I did was to change the application to open the file and double clicked on the icon. What I should also have done is to change the file extension to .pyw. When I do that the dialogs work as expected. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-10-06 21:59 Message: Logged In: YES user_id=45365 Bill, I think there's a misunderstanding here. Are you using PythonLauncher from the terminal? It isn't intended to be used as such, for that you should use "pythonw". If this is the problem let me know (it can probably be fixed, or PythonLauncher should complain). If it isn't what you're doing please give me a recipe to repeat this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 From noreply@sourceforge.net Tue Oct 8 10:30:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 02:30:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-558179 ] rfc822.Message.get() incompatibility Message-ID: Bugs item #558179, was opened at 2002-05-20 07:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: KAJIYAMA, Tamito (kajiyama) Assigned to: Guido van Rossum (gvanrossum) Summary: rfc822.Message.get() incompatibility Initial Comment: There is a backward incompatibility with Message.get() in the standard rfc822 module. I don't believe this incompatibility is intended to be introduced, so here is a bug report. In Python 2.2 and later, Message.get("foo") returns an empty string if the header field "foo" is not defined. In older versions of Python, on the other hand, it returns None. In fact, the definition of the method is duplicated in the Message class in in Python 2.2 and later, as follows: class Message: def getheader(self, name, default=None): ... get = getheader ... def get(self, name, default="") ... A possible fix would be to omit the later definition. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-08 09:30 Message: Logged In: YES user_id=4771 The documentation has not been completely updated. The default value returned by get() is said to be None at one point and the empty string at a later point (when the mapping interface of Message objects is discussed). Here is a patch (sorry, I cannot attach it -- no such field in the SF interface??): http://arigo.tunes.org/librfc822-diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 18:58 Message: Logged In: YES user_id=6380 You're so right. I'll delete the "def get(...)" version both in the 2.2 branch and in the head of CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470 From noreply@sourceforge.net Tue Oct 8 13:10:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 05:10:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-620179 ] __ipow__ broken for 'object's Message-ID: Bugs item #620179, was opened at 2002-10-08 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: __ipow__ broken for 'object's Initial Comment: class NewKlass(object): def __ipow__(self, i): self._ipow = i return self obj = NewKlass() obj **= 1 TypeError: __ipow__() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 From noreply@sourceforge.net Tue Oct 8 13:11:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 05:11:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-620179 ] __ipow__ broken for 'object's Message-ID: Bugs item #620179, was opened at 2002-10-08 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: __ipow__ broken for 'object's Initial Comment: class NewKlass(object): def __ipow__(self, i): self._ipow = i return self obj = NewKlass() obj **= 1 TypeError: __ipow__() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 From noreply@sourceforge.net Tue Oct 8 13:14:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 05:14:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-620181 ] float('+ 0.0') fails Message-ID: Bugs item #620181, was opened at 2002-10-08 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: float('+ 0.0') fails Initial Comment: In [25]: int('+ 0') Out[25]: 0 In [26]: float('+ 0.0') ValueError: invalid literal for float(): + 0.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 From noreply@sourceforge.net Tue Oct 8 13:26:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 05:26:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-620190 ] inspect and object instances Message-ID: Bugs item #620190, was opened at 2002-10-08 12:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: inspect and object instances Initial Comment: inspect.getargspec(NewKlass.aMethod) fails (which might technically be OK because the docs only mention functions, not methods) but I also vaguely seem to remember that some other operations in the inspect module only worked for oldstyle classes under 2.2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620190&group_id=5470 From noreply@sourceforge.net Tue Oct 8 13:27:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 05:27:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-620181 ] float('+ 0.0') fails Message-ID: Bugs item #620181, was opened at 2002-10-08 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None >Priority: 2 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: float('+ 0.0') fails Initial Comment: In [25]: int('+ 0') Out[25]: 0 In [26]: float('+ 0.0') ValueError: invalid literal for float(): + 0.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 From noreply@sourceforge.net Tue Oct 8 13:32:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 05:32:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-620193 ] bound method unbound Message-ID: Bugs item #620193, was opened at 2002-10-08 12:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: bound method unbound Initial Comment: >>> repr('NewKlass.classMethod') >>> type(NewKlass.classMethod) is types.UnboundMethodType 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 From noreply@sourceforge.net Tue Oct 8 15:11:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 07:11:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-620243 ] HTMLParser:endtag events in comments Message-ID: Bugs item #620243, was opened at 2002-10-08 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620243&group_id=5470 Category: Python Library Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: June Kim (juneaftn) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser:endtag events in comments Initial Comment: HTMLParser triggers events when met closing tags in comments. >>> from HTMLParser import HTMLParser >>> class P(HTMLParser): def handle_endtag(self,tag): print "ENDTAG",tag >>> p=P() >>> p.feed("""\ """) ENDTAG h1 ENDTAG script ENDTAG body ENDTAG html see http://groups.google.com/groups? selm=evkjmuohcuosh0tqgn2li03kfo7qknatsp% 404ax.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620243&group_id=5470 From noreply@sourceforge.net Tue Oct 8 15:26:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 07:26:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-558179 ] rfc822.Message.get() incompatibility Message-ID: Bugs item #558179, was opened at 2002-05-20 03:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470 >Category: Documentation Group: Python 2.2 >Status: Open Resolution: Fixed Priority: 5 Submitted By: KAJIYAMA, Tamito (kajiyama) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: rfc822.Message.get() incompatibility Initial Comment: There is a backward incompatibility with Message.get() in the standard rfc822 module. I don't believe this incompatibility is intended to be introduced, so here is a bug report. In Python 2.2 and later, Message.get("foo") returns an empty string if the header field "foo" is not defined. In older versions of Python, on the other hand, it returns None. In fact, the definition of the method is duplicated in the Message class in in Python 2.2 and later, as follows: class Message: def getheader(self, name, default=None): ... get = getheader ... def get(self, name, default="") ... A possible fix would be to omit the later definition. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 10:26 Message: Logged In: YES user_id=6380 Reopened and assigned to Fred for doc bug. (Armin: you can't attach files to an issue created by someone else -- unless you're a project admin.) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-08 05:30 Message: Logged In: YES user_id=4771 The documentation has not been completely updated. The default value returned by get() is said to be None at one point and the empty string at a later point (when the mapping interface of Message objects is discussed). Here is a patch (sorry, I cannot attach it -- no such field in the SF interface??): http://arigo.tunes.org/librfc822-diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 14:58 Message: Logged In: YES user_id=6380 You're so right. I'll delete the "def get(...)" version both in the 2.2 branch and in the head of CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470 From noreply@sourceforge.net Tue Oct 8 17:02:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 09:02:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-620181 ] float('+ 0.0') fails Message-ID: Bugs item #620181, was opened at 2002-10-08 08:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 2 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: float('+ 0.0') fails Initial Comment: In [25]: int('+ 0') Out[25]: 0 In [26]: float('+ 0.0') ValueError: invalid literal for float(): + 0.0 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-08 12:02 Message: Logged In: YES user_id=31435 Why do you think this is a bug? It's *generally* true that embedded whitespace isn't accepeted in numeric literals: >>> int("2 3") Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for int(): 2 3 >>> import string >>> string.atof("- 2") Traceback (most recent call last): File "", line 1, in ? File "C:\Code\python\lib\string.py", line 201, in atof return _float(s) ValueError: invalid literal for float(): - 2 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 From noreply@sourceforge.net Tue Oct 8 17:53:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 09:53:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Tue Oct 8 18:41:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 10:41:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-620181 ] float('+ 0.0') fails Message-ID: Bugs item #620181, was opened at 2002-10-08 12:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 2 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: float('+ 0.0') fails Initial Comment: In [25]: int('+ 0') Out[25]: 0 In [26]: float('+ 0.0') ValueError: invalid literal for float(): + 0.0 ---------------------------------------------------------------------- >Comment By: Alexander Schmolck (aschmolck) Date: 2002-10-08 17:41 Message: Logged In: YES user_id=559641 I don't feel strongly about this, it just seems a very minor inconsistency to me. It is not always true that embedded whitespace isn't accepted in numeric literals. Whitespace between sign and digits is discarded by `int`, but not by `float`. Also, in source code or in interactive sessions - 0.0 is treated as a float literal (not as unary negation of 0.0), wheras "2 3" just never works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-08 16:02 Message: Logged In: YES user_id=31435 Why do you think this is a bug? It's *generally* true that embedded whitespace isn't accepeted in numeric literals: >>> int("2 3") Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for int(): 2 3 >>> import string >>> string.atof("- 2") Traceback (most recent call last): File "", line 1, in ? File "C:\Code\python\lib\string.py", line 201, in atof return _float(s) ValueError: invalid literal for float(): - 2 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 From noreply@sourceforge.net Tue Oct 8 18:50:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 10:50:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-620364 ] core setup.py fails on Windows Message-ID: Bugs item #620364, was opened at 2002-10-08 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py fails on Windows Initial Comment: 1. Extract Python-2.2.2b1.tgz into a directory (E:\dev\python\src in this case). 2. Run 'python setup.py build' in the source root directory. 3. Witness the bug (output shown at the bottom of this message). The problem is that on line 81 of setup.py, the srcdir is set to None rather than a meaningful directory name (distutils.sysconfig.get_config_vars('srcdir') returns [None]). The traceback below arises on line 84, when None is passed as an argument to os.path.join. My operating system is Windows 2000, and I have MSVC 6 installed. The compiler is configured properly; I've built many other distutils-ified extensions without a hitch. This bug arises regardless of whether the Python-2.2.1 version of distutils or the Python-2.2.2b1 version of distutils is used (both versions are labeled as distutils 1.0.3). To generate the traceback shown below, I used the official Windows binary distribution of Python-2.2.1 (that is, the 'python' in 'python setup.py build' referred to Python-2.2.1), but the results are the same if I compile Python-2.2.2b1 by other means and then attempt to use the resulting executable to run its own distutils setup script. ---------------------------------------------------------- E:\dev\python\src\Python-2.2.2b1>python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 792, in ? main() File "setup.py", line 787, in main scripts = ['Tools/scripts/pydoc'] File "e:\dev\python\core\lib\distutils\core.py", line 138, in setup dist.run_commands() File "e:\dev\python\core\lib\distutils\dist.py", line 893, in run_commands self.run_command(cmd) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build.py", line 107, in run self.run_command(cmd_name) File "e:\dev\python\core\lib\distutils\cmd.py", line 330, in run_command self.distribution.run_command(command) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build_ext.py", line 256, in run self.build_extensions() File "setup.py", line 84, in build_extensions moddir = os.path.join(os.getcwd(), srcdir, 'Modules') File "E:\dev\python\core\Lib\ntpath.py", line 49, in join elif isabs(b): File "E:\dev\python\core\Lib\ntpath.py", line 35, in isabs s = splitdrive(s)[1] File "E:\dev\python\core\Lib\ntpath.py", line 101, in splitdrive if p[1:2] == ':': TypeError: unsubscriptable object ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 From noreply@sourceforge.net Tue Oct 8 19:23:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 11:23:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 12:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 14:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 12:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 13:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 15:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 20:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 17:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 11:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 14:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 12:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 12:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Tue Oct 8 20:40:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 12:40:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-620412 ] Max recursion limit with "*?" pattern Message-ID: Bugs item #620412, was opened at 2002-10-08 19:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620412&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Thorstein Thorsteinsson (thorstein) Assigned to: Fredrik Lundh (effbot) Summary: Max recursion limit with "*?" pattern Initial Comment: I ran into the following problem trying to parse an ms outlook mail box. Cut down to its bare essentials: > cat tst.py import re mstr = (11000*' ') + 'A' pattern = re.compile('.*?A') pattern.search(mstr) > python tst.py Traceback (most recent call last): File "tst.py", line 5, in ? pattern.search(mstr) RuntimeError: maximum recursion limit exceeded > python Python 2.2.1c1 (#6, Jul 20 2002, 09:40:07) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> The combination of a longish string with ".*?" gives the error. Using ".*" is ok. Could "non-greedy" matching be implemented non-recursively? If I understand correctly, the limit exceeded is USE_RECURSION_LIMIT in Modules/_sre.c. It is slightly confusing because we also have the Python recursion limit (my first reaction was to bump it up with sys.setrecursionlimit(), but that of course didn't help). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620412&group_id=5470 From noreply@sourceforge.net Wed Oct 9 07:27:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 23:27:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-620364 ] core setup.py fails on Windows Message-ID: Bugs item #620364, was opened at 2002-10-08 19:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py fails on Windows Initial Comment: 1. Extract Python-2.2.2b1.tgz into a directory (E:\dev\python\src in this case). 2. Run 'python setup.py build' in the source root directory. 3. Witness the bug (output shown at the bottom of this message). The problem is that on line 81 of setup.py, the srcdir is set to None rather than a meaningful directory name (distutils.sysconfig.get_config_vars('srcdir') returns [None]). The traceback below arises on line 84, when None is passed as an argument to os.path.join. My operating system is Windows 2000, and I have MSVC 6 installed. The compiler is configured properly; I've built many other distutils-ified extensions without a hitch. This bug arises regardless of whether the Python-2.2.1 version of distutils or the Python-2.2.2b1 version of distutils is used (both versions are labeled as distutils 1.0.3). To generate the traceback shown below, I used the official Windows binary distribution of Python-2.2.1 (that is, the 'python' in 'python setup.py build' referred to Python-2.2.1), but the results are the same if I compile Python-2.2.2b1 by other means and then attempt to use the resulting executable to run its own distutils setup script. ---------------------------------------------------------- E:\dev\python\src\Python-2.2.2b1>python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 792, in ? main() File "setup.py", line 787, in main scripts = ['Tools/scripts/pydoc'] File "e:\dev\python\core\lib\distutils\core.py", line 138, in setup dist.run_commands() File "e:\dev\python\core\lib\distutils\dist.py", line 893, in run_commands self.run_command(cmd) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build.py", line 107, in run self.run_command(cmd_name) File "e:\dev\python\core\lib\distutils\cmd.py", line 330, in run_command self.distribution.run_command(command) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build_ext.py", line 256, in run self.build_extensions() File "setup.py", line 84, in build_extensions moddir = os.path.join(os.getcwd(), srcdir, 'Modules') File "E:\dev\python\core\Lib\ntpath.py", line 49, in join elif isabs(b): File "E:\dev\python\core\Lib\ntpath.py", line 35, in isabs s = splitdrive(s)[1] File "E:\dev\python\core\Lib\ntpath.py", line 101, in splitdrive if p[1:2] == ':': TypeError: unsubscriptable object ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 08:27 Message: Logged In: YES user_id=21627 This is by design, the Python distribution itself is not build using setup.py, except for Cygwin targets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 From noreply@sourceforge.net Wed Oct 9 07:27:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 23:27:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-620193 ] bound method unbound Message-ID: Bugs item #620193, was opened at 2002-10-08 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: bound method unbound Initial Comment: >>> repr('NewKlass.classMethod') >>> type(NewKlass.classMethod) is types.UnboundMethodType 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 08:27 Message: Logged In: YES user_id=21627 Why is this a bug? Bound and unbound methods do have the same type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 From noreply@sourceforge.net Wed Oct 9 07:50:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 08 Oct 2002 23:50:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-620630 ] distutils mixed stdin/stdout output Message-ID: Bugs item #620630, was opened at 2002-10-09 06:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: distutils mixed stdin/stdout output Initial Comment: If distutils output is piped to a common logfile, the output is garbled as shown in: http://buildd.debian.org/fetch.php?&pkg=python-numeric&ver=22.0-2&arch=powerpc&stamp=1034115818&file=log&as=raw It's a bit confusing to search errors in the garbled output. It would be nice, if distutils flashes the output buffers on each newline. Not sure how well this shows in the included snippets. gcc-3.2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFSrc/ranlibmodule.c: In function `get_continuous_random': [here in the middle of the line] Src/ranlibmodule.c:47: warning: function declaration isn't a prototype Src/lapack_litemodule.c:649: warning: `lapack_liteError' defined but not used [upto here a compile command, then two other commands succeed, then the error for the link command] /usr/bin/ld: cannot find -lg2c-pic collect2: ld returned 1 exit status [and now the link command:] gcc-3.2 -shared build/temp.linux-ppc-2.3/lapack_litemodule.o -llapack -lblas -lg2c-pic -o build/lib.linux-ppc-2.3/lapack_lite.so error: command 'gcc-3.2' failed with exit status 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 From noreply@sourceforge.net Wed Oct 9 11:30:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 03:30:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-620705 ] websucker relative-URL errors Message-ID: Bugs item #620705, was opened at 2002-10-09 12:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: websucker relative-URL errors Initial Comment: reproduce easily with, e.g.: python websucker.py -v http://www.aleax.it gives a series of error messages such as: Check http://www.aleax.it/./py2.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/./py2.htm from http://www.aleax.it/./Python/ (///./py2.htm) Check http://www.aleax.it/p1.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/p1.htm from http://www.aleax.it/./TutWin32/index.htm (///p1.htm) but the relevant snippets of the HTML sources are e.g: in Python/index.html: in TutWin32/index.html: i.e. both relative URLs, so should resolve to the URLs of the files that ARE present, Python/py2.htm and TutWin32/p1.htm respectively. And indeed /usr/bin/wget has no problem fetching the whole small site. Pls let me know if you want me to explore the bug further and prepare a patch in time for 2.2.2 release -- otherwise I think this shd at least be documented as a known bug (making websucker close to unusable, alas). Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:23:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:23:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-620193 ] bound method unbound Message-ID: Bugs item #620193, was opened at 2002-10-08 12:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: bound method unbound Initial Comment: >>> repr('NewKlass.classMethod') >>> type(NewKlass.classMethod) is types.UnboundMethodType 1 ---------------------------------------------------------------------- >Comment By: Alexander Schmolck (aschmolck) Date: 2002-10-09 12:23 Message: Logged In: YES user_id=559641 Sorry, I should obviously have realized that.types.MethodType is types.UnboundMethodType. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 06:27 Message: Logged In: YES user_id=21627 Why is this a bug? Bound and unbound methods do have the same type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:23:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:23:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-620364 ] core setup.py fails on Windows Message-ID: Bugs item #620364, was opened at 2002-10-08 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py fails on Windows Initial Comment: 1. Extract Python-2.2.2b1.tgz into a directory (E:\dev\python\src in this case). 2. Run 'python setup.py build' in the source root directory. 3. Witness the bug (output shown at the bottom of this message). The problem is that on line 81 of setup.py, the srcdir is set to None rather than a meaningful directory name (distutils.sysconfig.get_config_vars('srcdir') returns [None]). The traceback below arises on line 84, when None is passed as an argument to os.path.join. My operating system is Windows 2000, and I have MSVC 6 installed. The compiler is configured properly; I've built many other distutils-ified extensions without a hitch. This bug arises regardless of whether the Python-2.2.1 version of distutils or the Python-2.2.2b1 version of distutils is used (both versions are labeled as distutils 1.0.3). To generate the traceback shown below, I used the official Windows binary distribution of Python-2.2.1 (that is, the 'python' in 'python setup.py build' referred to Python-2.2.1), but the results are the same if I compile Python-2.2.2b1 by other means and then attempt to use the resulting executable to run its own distutils setup script. ---------------------------------------------------------- E:\dev\python\src\Python-2.2.2b1>python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 792, in ? main() File "setup.py", line 787, in main scripts = ['Tools/scripts/pydoc'] File "e:\dev\python\core\lib\distutils\core.py", line 138, in setup dist.run_commands() File "e:\dev\python\core\lib\distutils\dist.py", line 893, in run_commands self.run_command(cmd) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build.py", line 107, in run self.run_command(cmd_name) File "e:\dev\python\core\lib\distutils\cmd.py", line 330, in run_command self.distribution.run_command(command) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build_ext.py", line 256, in run self.build_extensions() File "setup.py", line 84, in build_extensions moddir = os.path.join(os.getcwd(), srcdir, 'Modules') File "E:\dev\python\core\Lib\ntpath.py", line 49, in join elif isabs(b): File "E:\dev\python\core\Lib\ntpath.py", line 35, in isabs s = splitdrive(s)[1] File "E:\dev\python\core\Lib\ntpath.py", line 101, in splitdrive if p[1:2] == ':': TypeError: unsubscriptable object ---------------------------------------------------------------------- >Comment By: David Rushby (woodsplitter) Date: 2002-10-09 08:23 Message: Logged In: YES user_id=414645 > This is by design, the Python distribution itself is not build > using setup.py, except for Cygwin targets. I can accept that readily enough, but shouldn't setup.py raise a more meaningful error message, instead of gracelessly dumping a traceback that occurs when it tries to pass an erroneous value (None) to os.path.join? The current behavior may be by design, but to the uninitiated, it *very* strongly resembles a bug. Why not test srcdir (created on line 81 in the current setup.py) to see if it's a meaningful value, and raise an informative error message if not? Like this (line width ridiculously constrained for the sake of SF's forum): ################################################## (srcdir,) = sysconfig.get_config_vars('srcdir') if not srcDir: raise EnvironmentError("The system configuration" " variable 'srcdir' is not defined, so this" " setup script cannot continue. This error" " probably arose because this setup script" " is only designed to run in the Cygwin" " environment, yet you are attempting to" " run it elsewhere." ) ################################################## ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 02:27 Message: Logged In: YES user_id=21627 This is by design, the Python distribution itself is not build using setup.py, except for Cygwin targets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:39:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:39:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:42:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:42:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-620193 ] bound method unbound Message-ID: Bugs item #620193, was opened at 2002-10-08 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: bound method unbound Initial Comment: >>> repr('NewKlass.classMethod') >>> type(NewKlass.classMethod) is types.UnboundMethodType 1 ---------------------------------------------------------------------- Comment By: Alexander Schmolck (aschmolck) Date: 2002-10-09 14:23 Message: Logged In: YES user_id=559641 Sorry, I should obviously have realized that.types.MethodType is types.UnboundMethodType. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 08:27 Message: Logged In: YES user_id=21627 Why is this a bug? Bound and unbound methods do have the same type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620193&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:54:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:54:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 19:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-09 12:54 Message: Logged In: YES user_id=6656 Here's a patch that lets me compile the standard library and test suite with the compiler package and then run the test suite successfully. It does... oh, lots and lots of stuff. Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 10:08 Message: Logged In: YES user_id=6656 Here's a patch. Remarkably, it's just a one line patch to work around the SET_LINENO breakage. Other changes: * open the file for compiling in universal newlines mode. * always write the mtime to a .pyc little-endian-wise (2.2.2 candidate) * it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate) * bodge the parsermodule to return the encoding along with the encoding_decl non-terminal (this is pretty icky!) * let transformer cope with new 'testlist1' non-terminal * have transformer pick up the encoding declaration Still to do is using the encoding declaration to decode string literals. I think there should be an accessible from Python function to do this -- I really don't want to have to translate compile.c:parsestr into Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 15:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 09:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 16:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 09:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:55:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:55:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply@sourceforge.net Wed Oct 9 13:57:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 05:57:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build Message-ID: Bugs item #554916, was opened at 2002-05-11 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: M.-A. Lemburg (lemburg) Summary: test_unicode fails in wide unicode build Initial Comment: Assigned somewhat arbitrarily. It's a roundtrip test, I think. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-09 12:57 Message: Logged In: YES user_id=6656 Hmm. The test has stopped failing, so maybe we can close this. I'd be happier if I knew why, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 14:06 Message: Logged In: YES user_id=6656 Even better: $ ./python Adding parser accelerators ... Done. Python 2.2.1 (#1, May 13 2002, 15:02:01) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" 0 [18762 refs] but the test passes. And there was me thinking that it wasn't a problem on the release22-maint branch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 13:58 Message: Logged In: YES user_id=6656 >>> a = u"\udb00\udc00" [20811 refs] >>> b = unicode(a.encode("utf-8"), "utf-8") [21061 refs] >>> a, b (u'\U000d0000', u'\U000d0000') [21063 refs] >>> len(a), len(b) (2, 1) [21063 refs] Erm...? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-13 13:38 Message: Logged In: YES user_id=89016 The minimal failing testcase is: >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" False which is strange, because they *seem* to be the same: u"\udb00\udc00" u'\U000d0000' >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") u'\U000d0000' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 From noreply@sourceforge.net Wed Oct 9 15:18:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 07:18:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-620783 ] SocketServer/socket allow_reuse_address Message-ID: Bugs item #620783, was opened at 2002-10-09 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Notz (notz) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer/socket allow_reuse_address Initial Comment: The SocketServer.TCPServer.server_bind() method contains the following code: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) On SunOS and Linux (possibly others) this only appears to work if the third argument is changed to "2". Perhaps this is also a bug with the lower-level socket package's setsockopt() function (I mean, perhaps it *should* work with a value of "1"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 From noreply@sourceforge.net Wed Oct 9 15:25:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 07:25:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-620791 ] configure weakness on Solaris 5.8 Message-ID: Bugs item #620791, was opened at 2002-10-09 10:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620791&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nadia Dencheva (ndenchev) Assigned to: Nobody/Anonymous (nobody) Summary: configure weakness on Solaris 5.8 Initial Comment: Python version: 2.2.2b1 Operating system: Solaris 5.8 After checking for the presence of whar.h, configure failed to include it in the subsequent check for the size of wchar_t. A work around was to create configure from configure.in using a later version of autoconf (I used 2.53) which recognises the test AC_CHECK_SIZEOF with the syntax used: AC_CHECK_SIZEOF(wchar_t, 4, [#include ]) Note that default-includes can be used in this case because wchar_t is defined in stddef.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620791&group_id=5470 From noreply@sourceforge.net Wed Oct 9 16:54:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 08:54:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 07:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 10:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 07:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply@sourceforge.net Wed Oct 9 17:30:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 09:30:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-620181 ] float('+ 0.0') fails Message-ID: Bugs item #620181, was opened at 2002-10-08 07:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 2 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: float('+ 0.0') fails Initial Comment: In [25]: int('+ 0') Out[25]: 0 In [26]: float('+ 0.0') ValueError: invalid literal for float(): + 0.0 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 11:30 Message: Logged In: YES user_id=80475 Looking at the source for PyOS_strtol, it appears to be a implement quirk that int() accepts whitespace between the sign and the rest of the number. Since it's possible that people rely on the quirk (some accounting formats do print intermediate whitespace after the sign), this quirk probably should be left alone. float() uses platform's strtod() function which tries various strategies for making sense of the string. Liberalizing float () to match int()'s unintended quirk would involve trying to work around the strtod() black box and cluttering the code considerably. I recommend living with the minor inconsistency, closing the bug report, and moving on to bigger game. ---------------------------------------------------------------------- Comment By: Alexander Schmolck (aschmolck) Date: 2002-10-08 12:41 Message: Logged In: YES user_id=559641 I don't feel strongly about this, it just seems a very minor inconsistency to me. It is not always true that embedded whitespace isn't accepted in numeric literals. Whitespace between sign and digits is discarded by `int`, but not by `float`. Also, in source code or in interactive sessions - 0.0 is treated as a float literal (not as unary negation of 0.0), wheras "2 3" just never works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-08 11:02 Message: Logged In: YES user_id=31435 Why do you think this is a bug? It's *generally* true that embedded whitespace isn't accepeted in numeric literals: >>> int("2 3") Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for int(): 2 3 >>> import string >>> string.atof("- 2") Traceback (most recent call last): File "", line 1, in ? File "C:\Code\python\lib\string.py", line 201, in atof return _float(s) ValueError: invalid literal for float(): - 2 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 From noreply@sourceforge.net Wed Oct 9 18:38:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 10:38:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply@sourceforge.net Wed Oct 9 19:23:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 11:23:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-620921 ] urllib fails HTTPS - no SSL PRNG entropy Message-ID: Bugs item #620921, was opened at 2002-10-09 18:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620921&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: urllib fails HTTPS - no SSL PRNG entropy Initial Comment: solaris is stupid: it doesn't have a /dev/random or a /dev/urandom. therefore, openssl relies on the application to initialise the PRNG. the standard python library urllib.py (urlretrieve) will therefore fail to operate due to urllib.py not, itself, calling socket.RAND_egd() or RAND_add() as done in the test/test_socket_ssl.py code as an example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620921&group_id=5470 From noreply@sourceforge.net Wed Oct 9 19:25:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 11:25:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests Message-ID: Bugs item #451607, was opened at 2001-08-16 16:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Martin v. Löwis (loewis) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 18:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 19:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 18:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 18:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-03 15:12 Message: Logged In: YES user_id=21627 I'd suggest an approach similar to the one in test_socket, i.e. test only if can_fork. As for the certificates: I think they should be generated in advance and included into the test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 13:53 Message: Logged In: YES user_id=12800 There is currently an extremely minimal test in test_socket_ssl.py, but it is fairly bogus because it requires an outside network connection. The only test there just tries to hit https://sf.net. Ideally, there would be a set of regression tests that only required local resources. I.e. it would set up a local SSL server, then do connects to it to test the various SSL features in socket module. Take a look at test_socket_ssl.py in the 2.2 cvs and see if you can improve matters. From what I understand, the tricky part is generating all the necessary certificates, etc. Also, if you intend to work on this, please log in to SF to continue this dialog so we know who we're talking to! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-28 05:58 Message: Logged In: NO I may be able to help with this. I'm fairly familiar with SSL in general, though not about the socket module. What's needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 From noreply@sourceforge.net Wed Oct 9 20:53:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 12:53:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-620181 ] float('+ 0.0') fails Message-ID: Bugs item #620181, was opened at 2002-10-08 08:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 Category: Python Interpreter Core >Group: None >Status: Closed >Resolution: Wont Fix Priority: 2 Submitted By: Alexander Schmolck (aschmolck) >Assigned to: Tim Peters (tim_one) Summary: float('+ 0.0') fails Initial Comment: In [25]: int('+ 0') Out[25]: 0 In [26]: float('+ 0.0') ValueError: invalid literal for float(): + 0.0 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-09 15:53 Message: Logged In: YES user_id=31435 I agree with Raymond. There was no intent to allow embedded whitespace in numeric literals, and changing that now for the special case of a sign character in an integer literal would buy nothing except the possibility of breaking someone's code. So closing this as WontFix: you should consider int('+ 2') as broken code that CPython just happens to accept. The Language Reference manual doesn't allow for this possibility, so it's in the category of undefined behavior. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 12:30 Message: Logged In: YES user_id=80475 Looking at the source for PyOS_strtol, it appears to be a implement quirk that int() accepts whitespace between the sign and the rest of the number. Since it's possible that people rely on the quirk (some accounting formats do print intermediate whitespace after the sign), this quirk probably should be left alone. float() uses platform's strtod() function which tries various strategies for making sense of the string. Liberalizing float () to match int()'s unintended quirk would involve trying to work around the strtod() black box and cluttering the code considerably. I recommend living with the minor inconsistency, closing the bug report, and moving on to bigger game. ---------------------------------------------------------------------- Comment By: Alexander Schmolck (aschmolck) Date: 2002-10-08 13:41 Message: Logged In: YES user_id=559641 I don't feel strongly about this, it just seems a very minor inconsistency to me. It is not always true that embedded whitespace isn't accepted in numeric literals. Whitespace between sign and digits is discarded by `int`, but not by `float`. Also, in source code or in interactive sessions - 0.0 is treated as a float literal (not as unary negation of 0.0), wheras "2 3" just never works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-08 12:02 Message: Logged In: YES user_id=31435 Why do you think this is a bug? It's *generally* true that embedded whitespace isn't accepeted in numeric literals: >>> int("2 3") Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for int(): 2 3 >>> import string >>> string.atof("- 2") Traceback (most recent call last): File "", line 1, in ? File "C:\Code\python\lib\string.py", line 201, in atof return _float(s) ValueError: invalid literal for float(): - 2 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620181&group_id=5470 From noreply@sourceforge.net Wed Oct 9 22:16:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 14:16:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:04:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:04:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-621038 ] What's New - Expat listed twice Message-ID: Bugs item #621038, was opened at 2002-10-09 19:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: What's New - Expat listed twice Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: # The source code for the Expat XML parser is now included with the Python source, so the pyexpat module is no longer dependent on having a system library containing Expat. then a few lines later: # Python now includes a copy of the Expat XML parser's source code, removing any dependence on a system version or local installation of Expat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:05:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:05:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-621038 ] What's New - Expat listed twice Message-ID: Bugs item #621038, was opened at 2002-10-09 19:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Lalo Martins (lalo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: What's New - Expat listed twice Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: # The source code for the Expat XML parser is now included with the Python source, so the pyexpat module is no longer dependent on having a system library containing Expat. then a few lines later: # Python now includes a copy of the Expat XML parser's source code, removing any dependence on a system version or local installation of Expat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:07:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:07:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-621039 ] What's New - atheos link broken Message-ID: Bugs item #621039, was opened at 2002-10-09 19:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621039&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: What's New - atheos link broken Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: the link to atheos.cx is relative, so it resolves to http://www.python.org/dev/doc/devel/whatsnew/www.atheos.cx (which of course doesn't exist) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621039&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:08:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:08:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-621038 ] What's New - Expat listed twice Message-ID: Bugs item #621038, was opened at 2002-10-09 18:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Lalo Martins (lalo) >Assigned to: A.M. Kuchling (akuchling) Summary: What's New - Expat listed twice Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: # The source code for the Expat XML parser is now included with the Python source, so the pyexpat module is no longer dependent on having a system library containing Expat. then a few lines later: # Python now includes a copy of the Expat XML parser's source code, removing any dependence on a system version or local installation of Expat. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-09 18:08 Message: Logged In: YES user_id=3066 Assigned to "What's new" maintainer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:09:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:09:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-621039 ] What's New - atheos link broken Message-ID: Bugs item #621039, was opened at 2002-10-09 18:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621039&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) >Assigned to: A.M. Kuchling (akuchling) Summary: What's New - atheos link broken Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: the link to atheos.cx is relative, so it resolves to http://www.python.org/dev/doc/devel/whatsnew/www.atheos.cx (which of course doesn't exist) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-09 18:09 Message: Logged In: YES user_id=3066 Assigned to "What's new" maintainer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621039&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:27:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:27:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 19:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 22:27 Message: Logged In: YES user_id=31392 I'm listening, but it's going in one ear and out the other. I hope to have time for this later in the week. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 12:54 Message: Logged In: YES user_id=6656 Here's a patch that lets me compile the standard library and test suite with the compiler package and then run the test suite successfully. It does... oh, lots and lots of stuff. Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 10:08 Message: Logged In: YES user_id=6656 Here's a patch. Remarkably, it's just a one line patch to work around the SET_LINENO breakage. Other changes: * open the file for compiling in universal newlines mode. * always write the mtime to a .pyc little-endian-wise (2.2.2 candidate) * it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate) * bodge the parsermodule to return the encoding along with the encoding_decl non-terminal (this is pretty icky!) * let transformer cope with new 'testlist1' non-terminal * have transformer pick up the encoding declaration Still to do is using the encoding declaration to decode string literals. I think there should be an accessible from Python function to do this -- I really don't want to have to translate compile.c:parsestr into Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 15:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 09:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 16:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 09:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:34:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:34:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-558179 ] rfc822.Message.get() incompatibility Message-ID: Bugs item #558179, was opened at 2002-05-20 03:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: KAJIYAMA, Tamito (kajiyama) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: rfc822.Message.get() incompatibility Initial Comment: There is a backward incompatibility with Message.get() in the standard rfc822 module. I don't believe this incompatibility is intended to be introduced, so here is a bug report. In Python 2.2 and later, Message.get("foo") returns an empty string if the header field "foo" is not defined. In older versions of Python, on the other hand, it returns None. In fact, the definition of the method is duplicated in the Message class in in Python 2.2 and later, as follows: class Message: def getheader(self, name, default=None): ... get = getheader ... def get(self, name, default="") ... A possible fix would be to omit the later definition. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-09 18:34 Message: Logged In: YES user_id=3066 Committed Armin's patch and adjusted some nearby markup in Doc/lib/librfc822.tex 1.43 and 1.38.14.4. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 10:26 Message: Logged In: YES user_id=6380 Reopened and assigned to Fred for doc bug. (Armin: you can't attach files to an issue created by someone else -- unless you're a project admin.) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-08 05:30 Message: Logged In: YES user_id=4771 The documentation has not been completely updated. The default value returned by get() is said to be None at one point and the empty string at a later point (when the mapping interface of Message objects is discussed). Here is a patch (sorry, I cannot attach it -- no such field in the SF interface??): http://arigo.tunes.org/librfc822-diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 14:58 Message: Logged In: YES user_id=6380 You're so right. I'll delete the "def get(...)" version both in the 2.2 branch and in the head of CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470 From noreply@sourceforge.net Wed Oct 9 23:39:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 15:39:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-621057 ] File write examples are inadequate Message-ID: Bugs item #621057, was opened at 2002-10-09 16:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Stagg (kandrew) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: File write examples are inadequate Initial Comment: The examples provided for writing to files in section 7.2 of the documentation are overly simple showing only writing of a static string. Reading through 7.1 (although not actually discussing file I/O) helps a little as the % operator is mentioned but the "...C sprintf()-style format string..." specifiers which are valid aren't cross referenced (and the 'Library Reference' is a largish search area). I had to find out experimentally that %f isn't valid although %d is. To date, I haven't been able to experimentally findout how to print a list or tuple. trying: file.write('"%s"', str(relatedMeasurements)) results in: TypeError: read-only buffer, tuple The addition of examples printing a list or tuple would be extremely helpful. Similarly, examples of using file.write() to produce print type output would be very illuminating. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 From noreply@sourceforge.net Thu Oct 10 02:27:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 18:27:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 12:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-09 21:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 17:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 14:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 12:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 13:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 15:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 20:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 17:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 11:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 14:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 12:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 12:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Thu Oct 10 07:35:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 23:35:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-621157 ] Index entry bad Message-ID: Bugs item #621157, was opened at 2002-10-10 06:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621157&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip Ruggera (pruggera) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Index entry bad Initial Comment: Index entry for the open ststement doesn't go to open. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621157&group_id=5470 From noreply@sourceforge.net Thu Oct 10 07:37:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 09 Oct 2002 23:37:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-621157 ] Index entry bad in Language Reference Manual Message-ID: Bugs item #621157, was opened at 2002-10-10 06:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621157&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip Ruggera (pruggera) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Index entry bad in Language Reference Manual Initial Comment: Index entry for the open ststement doesn't go to open. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621157&group_id=5470 From noreply@sourceforge.net Thu Oct 10 09:13:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 01:13:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests Message-ID: Bugs item #451607, was opened at 2001-08-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Martin v. Löwis (loewis) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 10:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 20:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 21:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 20:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 20:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-03 17:12 Message: Logged In: YES user_id=21627 I'd suggest an approach similar to the one in test_socket, i.e. test only if can_fork. As for the certificates: I think they should be generated in advance and included into the test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 15:53 Message: Logged In: YES user_id=12800 There is currently an extremely minimal test in test_socket_ssl.py, but it is fairly bogus because it requires an outside network connection. The only test there just tries to hit https://sf.net. Ideally, there would be a set of regression tests that only required local resources. I.e. it would set up a local SSL server, then do connects to it to test the various SSL features in socket module. Take a look at test_socket_ssl.py in the 2.2 cvs and see if you can improve matters. From what I understand, the tricky part is generating all the necessary certificates, etc. Also, if you intend to work on this, please log in to SF to continue this dialog so we know who we're talking to! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-28 07:58 Message: Logged In: NO I may be able to help with this. I'm fairly familiar with SSL in general, though not about the socket module. What's needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 From noreply@sourceforge.net Thu Oct 10 09:39:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 01:39:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests Message-ID: Bugs item #451607, was opened at 2001-08-16 09:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Martin v. Löwis (loewis) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 01:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 01:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 11:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 12:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 11:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 11:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-03 08:12 Message: Logged In: YES user_id=21627 I'd suggest an approach similar to the one in test_socket, i.e. test only if can_fork. As for the certificates: I think they should be generated in advance and included into the test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 06:53 Message: Logged In: YES user_id=12800 There is currently an extremely minimal test in test_socket_ssl.py, but it is fairly bogus because it requires an outside network connection. The only test there just tries to hit https://sf.net. Ideally, there would be a set of regression tests that only required local resources. I.e. it would set up a local SSL server, then do connects to it to test the various SSL features in socket module. Take a look at test_socket_ssl.py in the 2.2 cvs and see if you can improve matters. From what I understand, the tricky part is generating all the necessary certificates, etc. Also, if you intend to work on this, please log in to SF to continue this dialog so we know who we're talking to! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-27 22:58 Message: Logged In: NO I may be able to help with this. I'm fairly familiar with SSL in general, though not about the socket module. What's needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 From noreply@sourceforge.net Thu Oct 10 09:51:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 01:51:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests Message-ID: Bugs item #451607, was opened at 2001-08-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Martin v. Löwis (loewis) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 10:51 Message: Logged In: YES user_id=21627 I don't think this is relevant here: OpenSSL uses whatever device it uses; we need not to concern ourselves with OpenSSL's choice. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 10:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 10:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 20:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 21:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2001-10-11 20:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 20:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-03 17:12 Message: Logged In: YES user_id=21627 I'd suggest an approach similar to the one in test_socket, i.e. test only if can_fork. As for the certificates: I think they should be generated in advance and included into the test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-08-28 15:53 Message: Logged In: YES user_id=12800 There is currently an extremely minimal test in test_socket_ssl.py, but it is fairly bogus because it requires an outside network connection. The only test there just tries to hit https://sf.net. Ideally, there would be a set of regression tests that only required local resources. I.e. it would set up a local SSL server, then do connects to it to test the various SSL features in socket module. Take a look at test_socket_ssl.py in the 2.2 cvs and see if you can improve matters. From what I understand, the tricky part is generating all the necessary certificates, etc. Also, if you intend to work on this, please log in to SF to continue this dialog so we know who we're talking to! :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-28 07:58 Message: Logged In: NO I may be able to help with this. I'm fairly familiar with SSL in general, though not about the socket module. What's needed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470 From noreply@sourceforge.net Thu Oct 10 10:38:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 02:38:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 19:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Jeremy Hylton (jhylton) Summary: compiler package and SET_LINENO Initial Comment: The compiler package should not issue SET_LINENO instructions any more. Running the Zope 2.7 test suite produces this traceback: Traceback (most recent call last): File "test.py", line 433, in ? process_args() File "test.py", line 397, in process_args bad = main(module_filter, test_filter) File "test.py", line 308, in main runner(files, test_filter, debug) File "test.py", line 275, in runner s = get_suite(file) File "test.py", line 230, in get_suite mod = package_import(modname) File "test.py", line 211, in package_import mod = __import__(modname) File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 64, in ? create_rmodule() File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/tests/testRestrictions.py", line 55, in create_rmodule code = compile_restricted(source, fn, 'exec') File "/home/fdrake/projects/Zope/Zope2.7/lib/python/RestrictedPython/RCompile.py", line 147, in compile_restricted gen.compile() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 123, in compile self.code = gen.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 378, in getCode self.convertArgs() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 484, in convertArgs self.insts[i] = opname, conv(self, oparg) File "/usr/local/lib/python2.3/compiler/pyassem.py", line 520, in _convert_LOAD_CONST arg = arg.getCode() File "/usr/local/lib/python2.3/compiler/pycodegen.py", line 252, in getCode return self.graph.getCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 380, in getCode self.makeByteCode() File "/usr/local/lib/python2.3/compiler/pyassem.py", line 585, in makeByteCode lnotab.addCode(self.opnum[opname], lo, hi) KeyError: SET_LINENO ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-10-10 09:38 Message: Logged In: YES user_id=6656 Ah good. Will wait for your comments. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 22:27 Message: Logged In: YES user_id=31392 I'm listening, but it's going in one ear and out the other. I hope to have time for this later in the week. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 12:54 Message: Logged In: YES user_id=6656 Here's a patch that lets me compile the standard library and test suite with the compiler package and then run the test suite successfully. It does... oh, lots and lots of stuff. Is anyone listening? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 10:08 Message: Logged In: YES user_id=6656 Here's a patch. Remarkably, it's just a one line patch to work around the SET_LINENO breakage. Other changes: * open the file for compiling in universal newlines mode. * always write the mtime to a .pyc little-endian-wise (2.2.2 candidate) * it's YIELD_VALUE, not YIELD_STMT (2.2.2 candidate) * bodge the parsermodule to return the encoding along with the encoding_decl non-terminal (this is pretty icky!) * let transformer cope with new 'testlist1' non-terminal * have transformer pick up the encoding declaration Still to do is using the encoding declaration to decode string literals. I think there should be an accessible from Python function to do this -- I really don't want to have to translate compile.c:parsestr into Python! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 09:38 Message: Logged In: YES user_id=6656 Hmm. I think I can fix the SET_LINENO breakage, but the compiler package is shafted in various other ways, notably by PEP 263. Fixing this seems to require a bewildering array of patches -- to symbol.py, to parsermodule, to token.py... I also found a couple of bugs, which I'll fix. Some of these should probably go into 2.2.2, too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-31 15:33 Message: Logged In: YES user_id=6656 I'm about to go away for a week, so if you want my help you'll probably have to wait until I get back. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-23 09:39 Message: Logged In: YES user_id=6656 Believe it or not, I'd actually got that far myself . If it'd been that easy, the changes would have been part of my original SET_LINENO removal patch. I guess the first question to answer is where does the lnotab live during compilation? In the CodeGenerator? Then logic has to move from PyFlowGraph.makeByteCode to CodeGenerator.set_lineno. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-22 16:39 Message: Logged In: YES user_id=31392 A grep for SET_LINENO in the compiler package source will be somewhat helpful. There are very few places that actually emit the instructions. I thought they could just be removed, but the lnotab is generated *from* the SET_LINENO instructions. So we need to come up with a different way to generate the lnotab. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-08-21 09:08 Message: Logged In: YES user_id=6656 This is my fault, obviously. I'm prepared to do some legwork to fix this problem, but don't really understand the code well enough to judge the best approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=597919&group_id=5470 From noreply@sourceforge.net Thu Oct 10 12:31:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 04:31:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-621038 ] What's New - Expat listed twice Message-ID: Bugs item #621038, was opened at 2002-10-09 18:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Lalo Martins (lalo) Assigned to: A.M. Kuchling (akuchling) Summary: What's New - Expat listed twice Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: # The source code for the Expat XML parser is now included with the Python source, so the pyexpat module is no longer dependent on having a system library containing Expat. then a few lines later: # Python now includes a copy of the Expat XML parser's source code, removing any dependence on a system version or local installation of Expat. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-10-10 07:31 Message: Logged In: YES user_id=11375 Duplicated entry removed; thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-09 18:08 Message: Logged In: YES user_id=3066 Assigned to "What's new" maintainer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621038&group_id=5470 From noreply@sourceforge.net Thu Oct 10 12:32:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 04:32:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-621039 ] What's New - atheos link broken Message-ID: Bugs item #621039, was opened at 2002-10-09 18:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621039&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lalo Martins (lalo) Assigned to: A.M. Kuchling (akuchling) Summary: What's New - atheos link broken Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html: the link to atheos.cx is relative, so it resolves to http://www.python.org/dev/doc/devel/whatsnew/www.atheos.cx (which of course doesn't exist) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-10-10 07:32 Message: Logged In: YES user_id=11375 Link fixed in CVS; thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-09 18:09 Message: Logged In: YES user_id=3066 Assigned to "What's new" maintainer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621039&group_id=5470 From noreply@sourceforge.net Thu Oct 10 16:07:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 08:07:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-620921 ] urllib fails HTTPS - no SSL PRNG entropy Message-ID: Bugs item #620921, was opened at 2002-10-09 20:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620921&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: urllib fails HTTPS - no SSL PRNG entropy Initial Comment: solaris is stupid: it doesn't have a /dev/random or a /dev/urandom. therefore, openssl relies on the application to initialise the PRNG. the standard python library urllib.py (urlretrieve) will therefore fail to operate due to urllib.py not, itself, calling socket.RAND_egd() or RAND_add() as done in the test/test_socket_ssl.py code as an example. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 17:07 Message: Logged In: YES user_id=21627 Invoking RAND_egd is not possible, since we don't know the EGD connect string. The test deliberately passes 1 to cause a TypeError. Invoking RAND_add should not be done, since we cannot come up with a random string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620921&group_id=5470 From noreply@sourceforge.net Thu Oct 10 16:30:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 08:30:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build Message-ID: Bugs item #554916, was opened at 2002-05-11 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: M.-A. Lemburg (lemburg) Summary: test_unicode fails in wide unicode build Initial Comment: Assigned somewhat arbitrarily. It's a roundtrip test, I think. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-10 15:30 Message: Logged In: YES user_id=38388 I'm not exactly sure why things work again, but I do know that I looked into this some time ago. Perhaps I simply forgot to close the bug or one of the UTF-8 codec overhauls remedied the problem. Here's what I get with python 2.3 UCS4: >>> len(u'\U000d0000') 1 >>> len(u"\udb00\udc00") 2 >>> u'\U000d0000' == u"\udb00\udc00" False >>> len(unicode(u"\udb00\udc00".encode('utf-8'), 'utf-8')) 1 >>> len(unicode(u'\U000d0000'.encode('utf-8'), 'utf-8')) 1 This is what I get with Python 2.2.1: >>> len(u'\U000d0000') 2 >>> len(u"\udb00\udc00") 2 >>> u'\U000d0000' == u"\udb00\udc00" 1 >>> len(unicode(u"\udb00\udc00".encode('utf-8'), 'utf-8')) 2 >>> len(unicode(u'\U000d0000'.encode('utf-8'), 'utf-8')) 2 There's still a difference there, but the UTF-8 codec behaves consistently. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 12:57 Message: Logged In: YES user_id=6656 Hmm. The test has stopped failing, so maybe we can close this. I'd be happier if I knew why, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 14:06 Message: Logged In: YES user_id=6656 Even better: $ ./python Adding parser accelerators ... Done. Python 2.2.1 (#1, May 13 2002, 15:02:01) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" 0 [18762 refs] but the test passes. And there was me thinking that it wasn't a problem on the release22-maint branch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 13:58 Message: Logged In: YES user_id=6656 >>> a = u"\udb00\udc00" [20811 refs] >>> b = unicode(a.encode("utf-8"), "utf-8") [21061 refs] >>> a, b (u'\U000d0000', u'\U000d0000') [21063 refs] >>> len(a), len(b) (2, 1) [21063 refs] Erm...? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-13 13:38 Message: Logged In: YES user_id=89016 The minimal failing testcase is: >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" False which is strange, because they *seem* to be the same: u"\udb00\udc00" u'\U000d0000' >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") u'\U000d0000' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 From noreply@sourceforge.net Thu Oct 10 16:27:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 08:27:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-620791 ] configure weakness on Solaris 5.8 Message-ID: Bugs item #620791, was opened at 2002-10-09 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620791&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nadia Dencheva (ndenchev) Assigned to: Nobody/Anonymous (nobody) Summary: configure weakness on Solaris 5.8 Initial Comment: Python version: 2.2.2b1 Operating system: Solaris 5.8 After checking for the presence of whar.h, configure failed to include it in the subsequent check for the size of wchar_t. A work around was to create configure from configure.in using a later version of autoconf (I used 2.53) which recognises the test AC_CHECK_SIZEOF with the syntax used: AC_CHECK_SIZEOF(wchar_t, 4, [#include ]) Note that default-includes can be used in this case because wchar_t is defined in stddef.h. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 17:27 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in configure 1.279.6.16; configure.in 1.288.6.16; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620791&group_id=5470 From noreply@sourceforge.net Thu Oct 10 16:56:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 08:56:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 12:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 19:51 Message: Logged In: YES user_id=4771 Hunting all overflow bugs seems like a long-term project :-) I can got along the source and submit patches as I find them, but at some point we will need a policy, like a common set of overflow-checking macros to compute the size of the memory to allocate or resize. Just for the fun, a couple more bugs: >>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 17:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 09:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 05:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Thu Oct 10 17:43:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 09:43:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-621157 ] Index entry bad in Language Reference Manual Message-ID: Bugs item #621157, was opened at 2002-10-10 02:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621157&group_id=5470 Category: Documentation >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Phillip Ruggera (pruggera) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Index entry bad in Language Reference Manual Initial Comment: Index entry for the open ststement doesn't go to open. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-10 12:43 Message: Logged In: YES user_id=3066 open() is not a statement but a built-in function. The index entry "open() (built-in function)" links to the description of the file object which mentions the open() function. Reference documentation for the open() function (actually an alias for the file built-in type) can be found in the Library Reference in the section on built-in functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621157&group_id=5470 From noreply@sourceforge.net Thu Oct 10 17:45:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 09:45:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-621447 ] RExec should allow sys.hexversion Message-ID: Bugs item #621447, was opened at 2002-10-10 12:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621447&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: RExec should allow sys.hexversion Initial Comment: rexec.RExec.ok_sys_names should include 'hexversion', since it includes 'version'. Currently 'import pickle' fails in a rexec because of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621447&group_id=5470 From noreply@sourceforge.net Thu Oct 10 18:12:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 10:12:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-621457 ] email: ASCII decoding error on 8bit data Message-ID: Bugs item #621457, was opened at 2002-10-10 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: email: ASCII decoding error on 8bit data Initial Comment: email 2.4.1 raises a UnicodeError when encountering 8-bit strings in rfc2822 message headers. Although this is not RFC compliant, it is commonly the case for spam messages originating from Asia. It was suggested on mimelib-devel that email should offer 'strict', 'ignore', and 'replace' modes for the programmer to decide what they want to do with invalid 8-bit data. This bug was discussed on the mimelib-devel list. See the thread starting at: http://article.gmane.org/gmane.comp.python.mime.devel/199 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 From noreply@sourceforge.net Thu Oct 10 18:13:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 10:13:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-621457 ] email: ASCII decoding error on 8bit data Message-ID: Bugs item #621457, was opened at 2002-10-10 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: ASCII decoding error on 8bit data Initial Comment: email 2.4.1 raises a UnicodeError when encountering 8-bit strings in rfc2822 message headers. Although this is not RFC compliant, it is commonly the case for spam messages originating from Asia. It was suggested on mimelib-devel that email should offer 'strict', 'ignore', and 'replace' modes for the programmer to decide what they want to do with invalid 8-bit data. This bug was discussed on the mimelib-devel list. See the thread starting at: http://article.gmane.org/gmane.comp.python.mime.devel/199 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 From noreply@sourceforge.net Thu Oct 10 19:47:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 11:47:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-621507 ] python22.dll incorrect "File version" Message-ID: Bugs item #621507, was opened at 2002-10-10 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jens Farmer (jensfarmer) Assigned to: Nobody/Anonymous (nobody) Summary: python22.dll incorrect "File version" Initial Comment: The win32 beta distribution 'Python-2.2.2b1.exe' contains the shared library 'Python22.dll'. Installing the distribution and inspecting the shared library (right-click or File | Properties), shows that the shared library's 'Version' is not quite correct. While the "Product Version" is set to "2.2.2b1", the "File version" is set to "2.2.14.1011" Didn't the previous distribution of 'Python22.dll' use the file version "2.2.16.1011?" Perhaps the file version is intentional but it seems like a reflection of an older build number. I installed 'Python-2.2.2b1.exe' on windows 2000 sp2 and I performed a clean install. (didn't overwrite any preexisting python distribution directories) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:09:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:09:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:35:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:35:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-621519 ] broken link in html reference manual Message-ID: Bugs item #621519, was opened at 2002-10-10 19:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621519&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: broken link in html reference manual Initial Comment: Debian report #161907 (seen as well at http://www.python.org/doc/current/ref/exceptions.html) Hello, I found a broken link in the HTML version of the Python Reference Manual. The page at file:///usr/share/doc/python2.2/html/ref/exceptions.html contains (near the bottom, the label is "7.4") a link to file:///usr/share/doc/python2.2/html/ref/node86.html#try This file does not exist. The correct name seems to be "try.html". I hope this helps, Jochen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621519&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:44:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:44:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-621523 ] sizeof(struct stat) changes Message-ID: Bugs item #621523, was opened at 2002-10-10 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 Category: None Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: sizeof(struct stat) changes Initial Comment: Including Python.h changes sizeof(struct stat): ralf@gandalf:~$ cat t.c #ifdef USE_PYTHON #include #endif #include main() { printf ("sizeof=%d\n", sizeof(struct stat)); } ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2 -DUSE_PYTHON && ./a.out sizeof=96 ralf@gandalf:~$ gcc t.c && ./a.out sizeof=88 ralf@gandalf:~$ uname -a Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002 i686 unknown rechecked with gcc-3.2 and current HEAD. Platform tests is Debian woody and Debian unstable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:46:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:46:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 12:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-10 15:46 Message: Logged In: YES user_id=31435 Note that the original problem here (the test_b1 segfault) "should have been" fixed, in 2.2.2 and 2.3, by a change to the test made yesterday. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 19:51 Message: Logged In: YES user_id=4771 Hunting all overflow bugs seems like a long-term project :-) I can got along the source and submit patches as I find them, but at some point we will need a policy, like a common set of overflow-checking macros to compute the size of the memory to allocate or resize. Just for the fun, a couple more bugs: >>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 17:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 09:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 05:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:48:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:48:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-607253 ] header file problems Message-ID: Bugs item #607253, was opened at 2002-09-10 03:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: header file problems Initial Comment: In connection with the Boost.Python library we are having problems due to missing extern "C" in some header files. This has prompted me to systematically look at all header files on the release22-maint branch and on the CVS trunk. The summary is shown below. The most severe problem are the missing extern "C" on the release-22-maint branch. Fortunately, this is fixed already on the CVS trunk. The next important problem is that the include guards are missing in pymactoolbox.h (both trunk and maint branch). I am not clear if there have to be include guards in files that only contain #defines (such as patchlevel.h) but having them would seem safer to me. Finally, the include guards in two files are not prefixed with Py_, Again, it would seem safter to me (reduce the chances of name clashes) if all Python include guards were consistently prefixed with Py_ . Ralf Python release22-maint cvs branch: extern "C" missing in: cStringIO.h descrobject.h iterobject.h include guards missing in: descrobject.h graminit.h iterobject.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h Python cvs head (Sep 9): include guards missing in: graminit.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-10-10 12:48 Message: Logged In: YES user_id=71407 Extensive tests using Python 2.2.2b1 on several platforms went without a problem. I suggest closing this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-04 05:51 Message: Logged In: YES user_id=33168 Backported the include guards/extern "C" for: * cStringIO.h 2.15.18.1 * descrobject.h 2.8.8.1 * iterobject.h 1.3.20.1 Fixed include guard prefix: * complexobject.h 2.11, 2.9.12.12.1 * cStringIO.h 2.9, 2.15.18.2 I'm leaving open for now, so I can discuss adding include guards for the other files (graminit.h, patchlevel.h, pyconfig.h). ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-09-23 21:56 Message: Logged In: YES user_id=71407 Patches for python-release22-maint as requested by Tim and Guido. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-10 05:34 Message: Logged In: YES user_id=45365 I've added the include guard to pymactoolbox.h. I've also added include guards and extern "C" constructs (where needed) to the include files in Mac/Include. The other ones I leave to someone else, esp. because I'm not sure things like graminit.h need them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 From noreply@sourceforge.net Thu Oct 10 20:49:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 12:49:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-621526 ] docs do not include accepted PEPs Message-ID: Bugs item #621526, was opened at 2002-10-10 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs do not include accepted PEPs Initial Comment: [please see http://bugs.debian.org/163703] The bug submitter complains, that the information found in accepted PEPs like 252 and 253 cannot be found in the "standard documentation" and proposes, that accepted PEPs are included in the standard documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 From noreply@sourceforge.net Thu Oct 10 21:25:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 13:25:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind Message-ID: Bugs item #621548, was opened at 2002-10-10 15:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jamin W. Collins (jamincollins) Assigned to: Nobody/Anonymous (nobody) Summary: Numerous defunct threads left behind Initial Comment: I originally noticed this problem with Debian's OfflineIMAP package and filed a report there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369 The short of it is that when running offlineimap for an extended period of time it will eventually leave a large number of defunct threads behind that eventually use up all available system processes. Killing the original offlineimap thread clears the problem for a while. The Debian maintainer of OfflineIMAP referred this over to the python maintainer, who in turn has asked (as you can see from the link above) that I file a report here. If there is any more information I can provide (beyond that in the Debian case already) please let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470 From noreply@sourceforge.net Thu Oct 10 21:32:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 13:32:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-621554 ] menues in emacs21 in transient mode Message-ID: Bugs item #621554, was opened at 2002-10-10 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: menues in emacs21 in transient mode Initial Comment: [from http://bugs.debian.org/160130 and http://bugs.debian.org/144653] python-elisp: Menus don't work under emacs21 in transient mark mode Under Emacs 21, any attempt to access the menus in python-mode fails unless the mark is active, with the message Debugger entered--Lisp error: (mark-inactive) signal(mark-inactive nil) mark() This happens only if transient-mark-mode (menu item: Options->Active Region Highlighting) is active and 'debug-on-error' is on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 From noreply@sourceforge.net Thu Oct 10 22:21:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 14:21:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-621579 ] test_sax fails on freebsd Message-ID: Bugs item #621579, was opened at 2002-10-10 17:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_sax fails on freebsd Initial Comment: test_sax consistently fails on the freebsd system on SF's compile farm. Fred said he'll look into it, so creating this bug report so he doesn't forget . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470 From noreply@sourceforge.net Thu Oct 10 22:26:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 14:26:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-621579 ] test_sax fails on freebsd Message-ID: Bugs item #621579, was opened at 2002-10-10 17:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None >Priority: 6 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_sax fails on freebsd Initial Comment: test_sax consistently fails on the freebsd system on SF's compile farm. Fred said he'll look into it, so creating this bug report so he doesn't forget . ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-10 17:26 Message: Logged In: YES user_id=3066 Here's the relevant part of the test output Barry emailed to me earlier. Hopefully it won't get too badly munged by SF. ;-) Failed test_expat_nsattrs_wattr Expected: [('start', ('http://xml.python.org/1', 'abc'), 'abc'), ('start', ('http://xml.python.org/2', 'def'), 'foo:def'), ('end', ('http://xml.python.org/2', 'def'), 'foo:def'), ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'), ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'), ('end', ('http://xml.python.org/1', 'abc'), 'abc')] Received: [('start', (u'http://xml.python.org/1', u'abc'), None), ('start', (u'http://xml.python.org/2', u'def'), None), ('end', (u'http://xml.python.org/2', u'def'), None), ('start', (u'http://xml.python.org/1', u'ghi'), None), ('end', (u'http://xml.python.org/1', u'ghi'), None), ('end', (u'http://xml.python.org/1', u'abc'), None)] Failed test_expat_nsdecl_pair_diff Expected: [('start', ('http://xml.python.org/', 'abc'), 'foo:abc'), ('start', ('http://xml.python.org/', 'def'), 'foo:def'), ('end', ('http://xml.python.org/', 'def'), 'foo:def'), ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')] Received: [('start', (u'http://xml.python.org/', u'abc'), None), ('start', (u'http://xml.python.org/', u'def'), None), ('end', (u'http://xml.python.org/', u'def'), None), ('start', (u'http://xml.python.org/', u'ghi'), None), ('end', (u'http://xml.python.org/', u'ghi'), None), ('end', (u'http://xml.python.org/', u'abc'), None)] Failed test_expat_nsdecl_pair_same Expected: [('start', ('http://xml.python.org/', 'abc'), 'abc'), ('end', ('http://xml.python.org/', 'abc'), 'abc')] Received: [('start', (u'http://xml.python.org/', u'abc'), None), ('end', (u'http://xml.python.org/', u'abc'), None)] Failed test_expat_nsdecl_single ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470 From noreply@sourceforge.net Thu Oct 10 22:59:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 14:59:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-621554 ] menues in emacs21 in transient mode Message-ID: Bugs item #621554, was opened at 2002-10-10 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: menues in emacs21 in transient mode Initial Comment: [from http://bugs.debian.org/160130 and http://bugs.debian.org/144653] python-elisp: Menus don't work under emacs21 in transient mark mode Under Emacs 21, any attempt to access the menus in python-mode fails unless the mark is active, with the message Debugger entered--Lisp error: (mark-inactive) signal(mark-inactive nil) mark() This happens only if transient-mark-mode (menu item: Options->Active Region Highlighting) is active and 'debug-on-error' is on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:11:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:11:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-621507 ] python22.dll incorrect "File version" Message-ID: Bugs item #621507, was opened at 2002-10-10 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 >Category: Windows Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jens Farmer (jensfarmer) >Assigned to: Tim Peters (tim_one) >Summary: python22.dll incorrect "File version" Initial Comment: The win32 beta distribution 'Python-2.2.2b1.exe' contains the shared library 'Python22.dll'. Installing the distribution and inspecting the shared library (right-click or File | Properties), shows that the shared library's 'Version' is not quite correct. While the "Product Version" is set to "2.2.2b1", the "File version" is set to "2.2.14.1011" Didn't the previous distribution of 'Python22.dll' use the file version "2.2.16.1011?" Perhaps the file version is intentional but it seems like a reflection of an older build number. I installed 'Python-2.2.2b1.exe' on windows 2000 sp2 and I performed a clean install. (didn't overwrite any preexisting python distribution directories) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:20:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:20:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-621507 ] python22.dll incorrect "File version" Message-ID: Bugs item #621507, was opened at 2002-10-10 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 Category: Windows >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Farmer (jensfarmer) >Assigned to: Mark Hammond (mhammond) >Summary: python22.dll incorrect "File version" Initial Comment: The win32 beta distribution 'Python-2.2.2b1.exe' contains the shared library 'Python22.dll'. Installing the distribution and inspecting the shared library (right-click or File | Properties), shows that the shared library's 'Version' is not quite correct. While the "Product Version" is set to "2.2.2b1", the "File version" is set to "2.2.14.1011" Didn't the previous distribution of 'Python22.dll' use the file version "2.2.16.1011?" Perhaps the file version is intentional but it seems like a reflection of an older build number. I installed 'Python-2.2.2b1.exe' on windows 2000 sp2 and I performed a clean install. (didn't overwrite any preexisting python distribution directories) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-10 18:20 Message: Logged In: YES user_id=31435 The first part of this appears to be claiming that "Product Version" and "File version" as shown by Explorer must be the same. If so, consider that part rejected. If not, please clarify the complaint. WRT the second part, right, the file version of Python 2.2.1's core DLL, as displayed by Explorer, was 2.2.16.1011. Our "build numbers" are auto-generated out of Python's major, minor, and micro release numbers, along with the release level and release serial numbers, and the Python API version. The exact formula used is in python_nt.rc. Explorer isn't displaying the number we build there, and I've no idea what's up with that. The value of FIELD3 (14 vs 16) is plain hosed. The value we set there for 2.2.2b1 was 2111, not 14. The value displayed for 2.2.1's core DLL doesn't make sense either. Beats me. Maybe MarkH has a clue ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:22:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:22:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-621523 ] sizeof(struct stat) changes Message-ID: Bugs item #621523, was opened at 2002-10-10 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 >Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: sizeof(struct stat) changes Initial Comment: Including Python.h changes sizeof(struct stat): ralf@gandalf:~$ cat t.c #ifdef USE_PYTHON #include #endif #include main() { printf ("sizeof=%d\n", sizeof(struct stat)); } ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2 -DUSE_PYTHON && ./a.out sizeof=96 ralf@gandalf:~$ gcc t.c && ./a.out sizeof=88 ralf@gandalf:~$ uname -a Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002 i686 unknown rechecked with gcc-3.2 and current HEAD. Platform tests is Debian woody and Debian unstable. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 18:22 Message: Logged In: YES user_id=33168 The problem is that Python is built with large file support. I'm running RedHat and your example works the same for me. It appears that _LARGEFILE64_SOURCE (_LARGEFILE_SOURCE on my system) is defined in pyconfig.h. So __USE_FILE_OFFSET64 gets defined in /usr/include/features.h. Python can be built without large file support, in which case the size will not change. Is this really a problem? Can it be solved by removing large file support from python? Can you include before including Python.h to solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 From noreply@sourceforge.net Thu Oct 10 23:30:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 15:30:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-621519 ] broken link in html reference manual Message-ID: Bugs item #621519, was opened at 2002-10-10 15:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621519&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: broken link in html reference manual Initial Comment: Debian report #161907 (seen as well at http://www.python.org/doc/current/ref/exceptions.html) Hello, I found a broken link in the HTML version of the Python Reference Manual. The page at file:///usr/share/doc/python2.2/html/ref/exceptions.html contains (near the bottom, the label is "7.4") a link to file:///usr/share/doc/python2.2/html/ref/node86.html#try This file does not exist. The correct name seems to be "try.html". I hope this helps, Jochen ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 18:30 Message: Logged In: YES user_id=33168 This is a duplicate of 217195 - http://python.org/sf/217195. Fred, it appears the ref is fine in the .tex, is there some place I could look to fix this problem? I don't know how to build the docs at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621519&group_id=5470 From noreply@sourceforge.net Fri Oct 11 01:47:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 17:47:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 12:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 20:47 Message: Logged In: YES user_id=6380 Fixed '%2147483647d' % -123 in 2.2.2 and 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-10 15:46 Message: Logged In: YES user_id=31435 Note that the original problem here (the test_b1 segfault) "should have been" fixed, in 2.2.2 and 2.3, by a change to the test made yesterday. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 19:51 Message: Logged In: YES user_id=4771 Hunting all overflow bugs seems like a long-term project :-) I can got along the source and submit patches as I find them, but at some point we will need a policy, like a common set of overflow-checking macros to compute the size of the memory to allocate or resize. Just for the fun, a couple more bugs: >>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 17:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 09:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 05:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Fri Oct 11 02:43:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 18:43:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerson Kurz (gersonkurz) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 21:43 Message: Logged In: YES user_id=33168 Do you know where python crashed? My guess was after a failed malloc. I tried testing this, but I don't have enough memory/cpu/patience to wait for loading such a large file. Can you make the test case smaller? What is the minimum size that still causes the seg fault? What version of cygwin? There is a known malloc problem in 1.3.12, see http://sources.redhat.com/ml/newlib/2002/msg00369.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Fri Oct 11 03:25:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 19:25:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-527521 ] httplib test causes SSL core dump Message-ID: Bugs item #527521, was opened at 2002-03-08 14:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: httplib test causes SSL core dump Initial Comment: The test() function in the httplib module attempts to connect to SourceForge using SSL. I've tried this with Python 2.1 and up, using OpenSSL 0.9.6. The read call fails with an SSL error, then python dumps core instead OpenSSL. I don't know if this is a Python bug or an SSL bug. At first blush, I'd guess that Python is probably using OpenSSL incorrectly. Here's the Python traceback. Traceback (most recent call last): File "../Lib/httplib.py", line 895, in ? test() File "../Lib/httplib.py", line 884, in test status, reason, headers = hs.getreply() File "../Lib/httplib.py", line 734, in getreply response = self._conn.getresponse() File "../Lib/httplib.py", line 579, in getresponse response = self.response_class(self.sock) File "../Lib/httplib.py", line 99, in __init__ self.fp = sock.makefile('rb', 0) File "../Lib/httplib.py", line 614, in makefile buf = self.__ssl.read() socket.sslerror: (1, 'error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number') And the gdb stack trace. #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 (gdb) bt #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 #1 0x40191068 in __DTOR_END__ () from /usr/local/ssl/lib/libssl.so.0.9.6 #2 0xe853 in ?? () Cannot access memory at address 0x5614ec83. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 22:25 Message: Logged In: YES user_id=33168 Jeremy, can this bug be closed? www.python.org is down. I tried sf.net and there was no crash. But I did get this exception: XXX strict mode should have failed I'm not sure if that's a problem or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-19 10:26 Message: Logged In: YES user_id=11375 This looks like a duplicate of bug #531616, though I didn't see Python dump core. Try it with the current httplib in CVS; it should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 From noreply@sourceforge.net Fri Oct 11 05:33:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 21:33:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-621708 ] Unclear deprecation referant:cuto-pasto? Message-ID: Bugs item #621708, was opened at 2002-10-11 04:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621708&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Unclear deprecation referant:cuto-pasto? Initial Comment: In the Language Reference (Python Reference Manual), Section 5.6 Binary arithmetic operations, At the end of the portion on "the % (modulo) operator," I see the following pair of paragraphs: Complex floor division operator, modulo operator, and divmod(). *Deprecated since release 2.3.* Instead convert to float using abs() if appropriate. The first paragraph is not a sentence (and I do not understand what sentence it wants to be). In the second It is not clear what is being deprecated. I suspect lost text. I would also suggest a link to string formatting info on this page, since this is where I went to look (expecting to find the operator % to mention the string uses). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621708&group_id=5470 From noreply@sourceforge.net Fri Oct 11 05:35:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Oct 2002 21:35:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-621708 ] Unclear deprecation referant:cuto-pasto? Message-ID: Bugs item #621708, was opened at 2002-10-10 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621708&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) >Assigned to: Raymond Hettinger (rhettinger) Summary: Unclear deprecation referant:cuto-pasto? Initial Comment: In the Language Reference (Python Reference Manual), Section 5.6 Binary arithmetic operations, At the end of the portion on "the % (modulo) operator," I see the following pair of paragraphs: Complex floor division operator, modulo operator, and divmod(). *Deprecated since release 2.3.* Instead convert to float using abs() if appropriate. The first paragraph is not a sentence (and I do not understand what sentence it wants to be). In the second It is not clear what is being deprecated. I suspect lost text. I would also suggest a link to string formatting info on this page, since this is where I went to look (expecting to find the operator % to mention the string uses). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621708&group_id=5470 From noreply@sourceforge.net Fri Oct 11 12:02:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 04:02:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-621523 ] sizeof(struct stat) changes Message-ID: Bugs item #621523, was opened at 2002-10-10 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: sizeof(struct stat) changes Initial Comment: Including Python.h changes sizeof(struct stat): ralf@gandalf:~$ cat t.c #ifdef USE_PYTHON #include #endif #include main() { printf ("sizeof=%d\n", sizeof(struct stat)); } ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2 -DUSE_PYTHON && ./a.out sizeof=96 ralf@gandalf:~$ gcc t.c && ./a.out sizeof=88 ralf@gandalf:~$ uname -a Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002 i686 unknown rechecked with gcc-3.2 and current HEAD. Platform tests is Debian woody and Debian unstable. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2002-10-11 11:02 Message: Logged In: YES user_id=17929 Well, at least it was a problem for me. I built a shared C++ library, where one of the classes had a private member of type struct stat and a virtual destructor, and had some subclasses of this class. Then I built a python module, linking against that library. When deleting those subclasses I got segfaults and it did take me pretty long to find out why this was happening (assuming at first that I had buffer over/underruns, then suspecting the compiler...). I essentially removed all of the code from the library and it was still segfaulting. I was really surprised when I changed that struct stat to a character array of same size... The problem here is within linux, if I would compile a standalone C++ program with largefile support, linking against that library, I would get the same results. But then at least I would have known, that I didn't use standard options to compile it. A solution for this problem would be to add a warning to python's documentation, or maybe move some of those defines from pyconfig.h to a private header file (assuming here that none of the structs declared in Python.h depend on struct stat. If they did, including sys/stat.h before Python.h might also be a bad idea). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 22:22 Message: Logged In: YES user_id=33168 The problem is that Python is built with large file support. I'm running RedHat and your example works the same for me. It appears that _LARGEFILE64_SOURCE (_LARGEFILE_SOURCE on my system) is defined in pyconfig.h. So __USE_FILE_OFFSET64 gets defined in /usr/include/features.h. Python can be built without large file support, in which case the size will not change. Is this really a problem? Can it be solved by removing large file support from python? Can you include before including Python.h to solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 From noreply@sourceforge.net Fri Oct 11 12:28:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 04:28:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-08 00:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Piers Lauder (pierslauder) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2002-10-11 21:28 Message: Logged In: YES user_id=196212 Certainly the wrong behaviour! In order to nail down the source of the problem, would you kindly run "imaplib.py -d5 ..." in a way that demontrates the bug and email me with the entire output? (Send it to ) That should make clear why the code that deals with the {nnn} form isn't picking this up. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Fri Oct 11 14:10:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 06:10:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-607253 ] header file problems Message-ID: Bugs item #607253, was opened at 2002-09-10 06:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: header file problems Initial Comment: In connection with the Boost.Python library we are having problems due to missing extern "C" in some header files. This has prompted me to systematically look at all header files on the release22-maint branch and on the CVS trunk. The summary is shown below. The most severe problem are the missing extern "C" on the release-22-maint branch. Fortunately, this is fixed already on the CVS trunk. The next important problem is that the include guards are missing in pymactoolbox.h (both trunk and maint branch). I am not clear if there have to be include guards in files that only contain #defines (such as patchlevel.h) but having them would seem safer to me. Finally, the include guards in two files are not prefixed with Py_, Again, it would seem safter to me (reduce the chances of name clashes) if all Python include guards were consistently prefixed with Py_ . Ralf Python release22-maint cvs branch: extern "C" missing in: cStringIO.h descrobject.h iterobject.h include guards missing in: descrobject.h graminit.h iterobject.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h Python cvs head (Sep 9): include guards missing in: graminit.h patchlevel.h pymactoolbox.h (pyconfig.h) include guard does not start with "Py_": complexobject.h cStringIO.h ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 09:10 Message: Logged In: YES user_id=33168 >From discussion on python-dev, there's not much to be gained by adding multiple header protection for graminit.h, patchlevel.h, and pyconfig.h. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-10-10 15:48 Message: Logged In: YES user_id=71407 Extensive tests using Python 2.2.2b1 on several platforms went without a problem. I suggest closing this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-04 08:51 Message: Logged In: YES user_id=33168 Backported the include guards/extern "C" for: * cStringIO.h 2.15.18.1 * descrobject.h 2.8.8.1 * iterobject.h 1.3.20.1 Fixed include guard prefix: * complexobject.h 2.11, 2.9.12.12.1 * cStringIO.h 2.9, 2.15.18.2 I'm leaving open for now, so I can discuss adding include guards for the other files (graminit.h, patchlevel.h, pyconfig.h). ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2002-09-24 00:56 Message: Logged In: YES user_id=71407 Patches for python-release22-maint as requested by Tim and Guido. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-10 08:34 Message: Logged In: YES user_id=45365 I've added the include guard to pymactoolbox.h. I've also added include guards and extern "C" constructs (where needed) to the include files in Mac/Include. The other ones I leave to someone else, esp. because I'm not sure things like graminit.h need them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607253&group_id=5470 From noreply@sourceforge.net Fri Oct 11 14:13:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 06:13:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-20 19:56 You can respond by visiting: https://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-10-11 09:13 Message: Logged In: YES user_id=3066 Galeon support has been added in revision 1.33. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-09-08 05:47 Message: Logged In: YES user_id=60903 Attached is a patch, which changes _tryorder to try the text-based browsers first in absence of the DISPLAY environment. No change for the case where BROWSER is set. Should the module take care of the case, where BROWSER is set to i.e. mozilla and you're running on the console? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 09: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 09: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 08: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 05: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 17: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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Fri Oct 11 15:47:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 07:47:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-527521 ] httplib strict mode fails in 2.2.2 Message-ID: Bugs item #527521, was opened at 2002-03-08 19:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) >Summary: httplib strict mode fails in 2.2.2 Initial Comment: The test() function in the httplib module attempts to connect to SourceForge using SSL. I've tried this with Python 2.1 and up, using OpenSSL 0.9.6. The read call fails with an SSL error, then python dumps core instead OpenSSL. I don't know if this is a Python bug or an SSL bug. At first blush, I'd guess that Python is probably using OpenSSL incorrectly. Here's the Python traceback. Traceback (most recent call last): File "../Lib/httplib.py", line 895, in ? test() File "../Lib/httplib.py", line 884, in test status, reason, headers = hs.getreply() File "../Lib/httplib.py", line 734, in getreply response = self._conn.getresponse() File "../Lib/httplib.py", line 579, in getresponse response = self.response_class(self.sock) File "../Lib/httplib.py", line 99, in __init__ self.fp = sock.makefile('rb', 0) File "../Lib/httplib.py", line 614, in makefile buf = self.__ssl.read() socket.sslerror: (1, 'error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number') And the gdb stack trace. #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 (gdb) bt #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 #1 0x40191068 in __DTOR_END__ () from /usr/local/ssl/lib/libssl.so.0.9.6 #2 0xe853 in ?? () Cannot access memory at address 0x5614ec83. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 14:47 Message: Logged In: YES user_id=31392 I don't see the coredump either; the C code is very different in 2.1, so it's probably a 2.1-specific bug. But the XXX strict mode problem in 2.2 is probably a bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 02:25 Message: Logged In: YES user_id=33168 Jeremy, can this bug be closed? www.python.org is down. I tried sf.net and there was no crash. But I did get this exception: XXX strict mode should have failed I'm not sure if that's a problem or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-19 15:26 Message: Logged In: YES user_id=11375 This looks like a duplicate of bug #531616, though I didn't see Python dump core. Try it with the current httplib in CVS; it should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 From noreply@sourceforge.net Fri Oct 11 15:48:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 07:48:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-621526 ] docs do not include accepted PEPs Message-ID: Bugs item #621526, was opened at 2002-10-10 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs do not include accepted PEPs Initial Comment: [please see http://bugs.debian.org/163703] The bug submitter complains, that the information found in accepted PEPs like 252 and 253 cannot be found in the "standard documentation" and proposes, that accepted PEPs are included in the standard documentation. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 14:48 Message: Logged In: YES user_id=31392 I don't think PEPs themselves should be included in the documentation, but the relevant spec info should go into the docs in an appropriate location. I think leaving the rationale/discussion part in the PEP is good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 From noreply@sourceforge.net Fri Oct 11 16:40:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 08:40:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 16:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 15:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 01:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 21:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 18:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 16:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 17:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 19:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 00:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 21:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 21:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 21:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 15:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 18:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 16:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 00:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 16:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Fri Oct 11 16:42:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 08:42:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-620921 ] urllib fails HTTPS - no SSL PRNG entropy Message-ID: Bugs item #620921, was opened at 2002-10-09 18:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620921&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: urllib fails HTTPS - no SSL PRNG entropy Initial Comment: solaris is stupid: it doesn't have a /dev/random or a /dev/urandom. therefore, openssl relies on the application to initialise the PRNG. the standard python library urllib.py (urlretrieve) will therefore fail to operate due to urllib.py not, itself, calling socket.RAND_egd() or RAND_add() as done in the test/test_socket_ssl.py code as an example. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 15:42 Message: Logged In: YES user_id=31392 There's nothing Python can do by default to cope with a system where OpenSSL doesn't initialize the PRNG by itself. So users must either upgrade to a version of OpenSSL that does the initialization or do its themselves (perhaps in a PYTHONSTARTUP script). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 15:07 Message: Logged In: YES user_id=21627 Invoking RAND_egd is not possible, since we don't know the EGD connect string. The test deliberately passes 1 to cause a TypeError. Invoking RAND_add should not be done, since we cannot come up with a random string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620921&group_id=5470 From noreply@sourceforge.net Fri Oct 11 16:56:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 08:56:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-621447 ] RExec should allow sys.hexversion Message-ID: Bugs item #621447, was opened at 2002-10-10 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621447&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: RExec should allow sys.hexversion Initial Comment: rexec.RExec.ok_sys_names should include 'hexversion', since it includes 'version'. Currently 'import pickle' fails in a rexec because of this. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 15:56 Message: Logged In: YES user_id=31392 Fixed in rev 1.42 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621447&group_id=5470 From noreply@sourceforge.net Fri Oct 11 17:16:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 09:16:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-620630 ] distutils mixed stdin/stdout output Message-ID: Bugs item #620630, was opened at 2002-10-09 06:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: distutils mixed stdin/stdout output Initial Comment: If distutils output is piped to a common logfile, the output is garbled as shown in: http://buildd.debian.org/fetch.php?&pkg=python-numeric&ver=22.0-2&arch=powerpc&stamp=1034115818&file=log&as=raw It's a bit confusing to search errors in the garbled output. It would be nice, if distutils flashes the output buffers on each newline. Not sure how well this shows in the included snippets. gcc-3.2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFSrc/ranlibmodule.c: In function `get_continuous_random': [here in the middle of the line] Src/ranlibmodule.c:47: warning: function declaration isn't a prototype Src/lapack_litemodule.c:649: warning: `lapack_liteError' defined but not used [upto here a compile command, then two other commands succeed, then the error for the link command] /usr/bin/ld: cannot find -lg2c-pic collect2: ld returned 1 exit status [and now the link command:] gcc-3.2 -shared build/temp.linux-ppc-2.3/lapack_litemodule.o -llapack -lblas -lg2c-pic -o build/lib.linux-ppc-2.3/lapack_lite.so error: command 'gcc-3.2' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:16 Message: Logged In: YES user_id=31392 If you're piping the output to a combined log file, you can use python -u to unbuffer stdout. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 From noreply@sourceforge.net Fri Oct 11 18:14:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 10:14:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 19:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-10-11 17:14 Message: Logged In: YES user_id=33229 You're right - there should be values returned. Ideally, getselection should return a Python list, not just a Tcl string which is a list to Tcl. Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Fri Oct 11 18:20:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 10:20:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) >Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 17:20 Message: Logged In: YES user_id=31392 Doesn't look like this is still a problem, but waiting to close until we hear for certain. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 17:54 Message: Logged In: YES user_id=565165 I was able to get 2.3 to build (with the latest stuff from CVS) and the problem seems to be fixed. I'll try and update 2.2.1 when I have some time and test that. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 16:29 Message: Logged In: YES user_id=33168 Tim apparently fixed this problem in 2.3, at least he fixed a problem. :-) Could you test w/2.3 and/or 2.2.1+ (do a cvs upd -r release22-maint)? 2.2.1+ has bug fixes that will be rolled into 2.2.2. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 14:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 22:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Fri Oct 11 18:45:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 10:45:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-621507 ] python22.dll incorrect "File version" Message-ID: Bugs item #621507, was opened at 2002-10-10 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Farmer (jensfarmer) Assigned to: Mark Hammond (mhammond) >Summary: python22.dll incorrect "File version" Initial Comment: The win32 beta distribution 'Python-2.2.2b1.exe' contains the shared library 'Python22.dll'. Installing the distribution and inspecting the shared library (right-click or File | Properties), shows that the shared library's 'Version' is not quite correct. While the "Product Version" is set to "2.2.2b1", the "File version" is set to "2.2.14.1011" Didn't the previous distribution of 'Python22.dll' use the file version "2.2.16.1011?" Perhaps the file version is intentional but it seems like a reflection of an older build number. I installed 'Python-2.2.2b1.exe' on windows 2000 sp2 and I performed a clean install. (didn't overwrite any preexisting python distribution directories) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-11 13:45 Message: Logged In: YES user_id=31435 Oh, dear. What File | Properties displays also differs across Windows versions. The Win98 Explorer displays the string names ("FileVersion" and "ProductVersion") for both fields. The Win2K Explorer displays the string name for the latter, but the fixed-info FILEVERSION for the former. The third FILEVERSION field is definitely hosed. It's 16 for 2.2.1 final, 14 for 2.2.1b1, and 11(!) for current CVS Python 2.3a0. The definition of FIELD3 is montonically increasing, though: #define FIELD3 (PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 + PY_RELEASE_SERIAL) I'm left guessing it's a bug in the MS resource compiler (wouldn't be the first). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-10 18:20 Message: Logged In: YES user_id=31435 The first part of this appears to be claiming that "Product Version" and "File version" as shown by Explorer must be the same. If so, consider that part rejected. If not, please clarify the complaint. WRT the second part, right, the file version of Python 2.2.1's core DLL, as displayed by Explorer, was 2.2.16.1011. Our "build numbers" are auto-generated out of Python's major, minor, and micro release numbers, along with the release level and release serial numbers, and the Python API version. The exact formula used is in python_nt.rc. Explorer isn't displaying the number we build there, and I've no idea what's up with that. The value of FIELD3 (14 vs 16) is plain hosed. The value we set there for 2.2.2b1 was 2111, not 14. The value displayed for 2.2.1's core DLL doesn't make sense either. Beats me. Maybe MarkH has a clue ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 From noreply@sourceforge.net Fri Oct 11 19:34:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 11:34:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-621507 ] python22.dll incorrect "File version" Message-ID: Bugs item #621507, was opened at 2002-10-10 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Farmer (jensfarmer) >Assigned to: Tim Peters (tim_one) >Summary: python22.dll incorrect "File version" Initial Comment: The win32 beta distribution 'Python-2.2.2b1.exe' contains the shared library 'Python22.dll'. Installing the distribution and inspecting the shared library (right-click or File | Properties), shows that the shared library's 'Version' is not quite correct. While the "Product Version" is set to "2.2.2b1", the "File version" is set to "2.2.14.1011" Didn't the previous distribution of 'Python22.dll' use the file version "2.2.16.1011?" Perhaps the file version is intentional but it seems like a reflection of an older build number. I installed 'Python-2.2.2b1.exe' on windows 2000 sp2 and I performed a clean install. (didn't overwrite any preexisting python distribution directories) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-11 14:34 Message: Logged In: YES user_id=31435 Reassigned to me, since I'm fixing it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-11 13:45 Message: Logged In: YES user_id=31435 Oh, dear. What File | Properties displays also differs across Windows versions. The Win98 Explorer displays the string names ("FileVersion" and "ProductVersion") for both fields. The Win2K Explorer displays the string name for the latter, but the fixed-info FILEVERSION for the former. The third FILEVERSION field is definitely hosed. It's 16 for 2.2.1 final, 14 for 2.2.1b1, and 11(!) for current CVS Python 2.3a0. The definition of FIELD3 is montonically increasing, though: #define FIELD3 (PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 + PY_RELEASE_SERIAL) I'm left guessing it's a bug in the MS resource compiler (wouldn't be the first). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-10 18:20 Message: Logged In: YES user_id=31435 The first part of this appears to be claiming that "Product Version" and "File version" as shown by Explorer must be the same. If so, consider that part rejected. If not, please clarify the complaint. WRT the second part, right, the file version of Python 2.2.1's core DLL, as displayed by Explorer, was 2.2.16.1011. Our "build numbers" are auto-generated out of Python's major, minor, and micro release numbers, along with the release level and release serial numbers, and the Python API version. The exact formula used is in python_nt.rc. Explorer isn't displaying the number we build there, and I've no idea what's up with that. The value of FIELD3 (14 vs 16) is plain hosed. The value we set there for 2.2.2b1 was 2111, not 14. The value displayed for 2.2.1's core DLL doesn't make sense either. Beats me. Maybe MarkH has a clue ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 From noreply@sourceforge.net Fri Oct 11 19:41:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 11:41:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-621507 ] python22.dll incorrect "File version" Message-ID: Bugs item #621507, was opened at 2002-10-10 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jens Farmer (jensfarmer) Assigned to: Tim Peters (tim_one) >Summary: python22.dll incorrect "File version" Initial Comment: The win32 beta distribution 'Python-2.2.2b1.exe' contains the shared library 'Python22.dll'. Installing the distribution and inspecting the shared library (right-click or File | Properties), shows that the shared library's 'Version' is not quite correct. While the "Product Version" is set to "2.2.2b1", the "File version" is set to "2.2.14.1011" Didn't the previous distribution of 'Python22.dll' use the file version "2.2.16.1011?" Perhaps the file version is intentional but it seems like a reflection of an older build number. I installed 'Python-2.2.2b1.exe' on windows 2000 sp2 and I performed a clean install. (didn't overwrite any preexisting python distribution directories) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-11 14:41 Message: Logged In: YES user_id=31435 Gave up on trying to convince rc to do arithmetic correctly. We plug the correct value in by hand now instead. Rebuilding the 2.2.2b1 release does set the third fileversion int to 2111 now, as the code tried to do all along. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-11 14:34 Message: Logged In: YES user_id=31435 Reassigned to me, since I'm fixing it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-11 13:45 Message: Logged In: YES user_id=31435 Oh, dear. What File | Properties displays also differs across Windows versions. The Win98 Explorer displays the string names ("FileVersion" and "ProductVersion") for both fields. The Win2K Explorer displays the string name for the latter, but the fixed-info FILEVERSION for the former. The third FILEVERSION field is definitely hosed. It's 16 for 2.2.1 final, 14 for 2.2.1b1, and 11(!) for current CVS Python 2.3a0. The definition of FIELD3 is montonically increasing, though: #define FIELD3 (PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 + PY_RELEASE_SERIAL) I'm left guessing it's a bug in the MS resource compiler (wouldn't be the first). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-10 18:20 Message: Logged In: YES user_id=31435 The first part of this appears to be claiming that "Product Version" and "File version" as shown by Explorer must be the same. If so, consider that part rejected. If not, please clarify the complaint. WRT the second part, right, the file version of Python 2.2.1's core DLL, as displayed by Explorer, was 2.2.16.1011. Our "build numbers" are auto-generated out of Python's major, minor, and micro release numbers, along with the release level and release serial numbers, and the Python API version. The exact formula used is in python_nt.rc. Explorer isn't displaying the number we build there, and I've no idea what's up with that. The value of FIELD3 (14 vs 16) is plain hosed. The value we set there for 2.2.2b1 was 2111, not 14. The value displayed for 2.2.1's core DLL doesn't make sense either. Beats me. Maybe MarkH has a clue ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621507&group_id=5470 From noreply@sourceforge.net Fri Oct 11 20:57:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 12:57:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- >Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 14:57 Message: Logged In: YES user_id=626964 You are right. How would this look? def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-10-11 12:14 Message: Logged In: YES user_id=33229 You're right - there should be values returned. Ideally, getselection should return a Python list, not just a Tcl string which is a list to Tcl. Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Fri Oct 11 21:10:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 13:10:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- >Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 15:10 Message: Logged In: YES user_id=626964 Forgot the case with no selection: def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: if len(x) > 0: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 14:57 Message: Logged In: YES user_id=626964 You are right. How would this look? def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-10-11 12:14 Message: Logged In: YES user_id=33229 You're right - there should be values returned. Ideally, getselection should return a Python list, not just a Tcl string which is a list to Tcl. Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Fri Oct 11 21:15:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 13:15:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-622042 ] httplib HEAD request fails - keepalive Message-ID: Bugs item #622042, was opened at 2002-10-11 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: httplib HEAD request fails - keepalive Initial Comment: httplib fails to handle HEAD requests correctly when the server side honors a keep-alive connection. Per RFC2616, sect. 9.4: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in the response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This means that HEAD requests are likely to return a non-zero Content-Length, but with no body. The attached script, if called against an HTTP/1.1, keep-alive-aware server (try www.microsoft.com or www.redhat.com) will hang instead of finishing, because read() will expect to read some bytes from the connection. The script was tested against version 1.66 of httplib (the current HEAD). HTTP/1.0 and Connection: close (with HTTP/1.1) work as expected because the server closes the connection. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 From noreply@sourceforge.net Fri Oct 11 21:44:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 13:44:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 12:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 16:44 Message: Logged In: YES user_id=6380 Fixed 1L<>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 17:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 09:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 05:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Fri Oct 11 22:00:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 14:00:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-621708 ] Unclear deprecation referant:cuto-pasto? Message-ID: Bugs item #621708, was opened at 2002-10-10 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621708&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Raymond Hettinger (rhettinger) Summary: Unclear deprecation referant:cuto-pasto? Initial Comment: In the Language Reference (Python Reference Manual), Section 5.6 Binary arithmetic operations, At the end of the portion on "the % (modulo) operator," I see the following pair of paragraphs: Complex floor division operator, modulo operator, and divmod(). *Deprecated since release 2.3.* Instead convert to float using abs() if appropriate. The first paragraph is not a sentence (and I do not understand what sentence it wants to be). In the second It is not clear what is being deprecated. I suspect lost text. I would also suggest a link to string formatting info on this page, since this is where I went to look (expecting to find the operator % to mention the string uses). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-11 16:00 Message: Logged In: YES user_id=80475 Replaced with: *Deprecated since release 2.3* the floor division operator, the modulo operator, and the divmod() function are no longer defined for complex numbers. Instead, convert to a floating point number using the abs() function if appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621708&group_id=5470 From noreply@sourceforge.net Fri Oct 11 22:13:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 14:13:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 12:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 17:13 Message: Logged In: YES user_id=6380 OK, I think I see what you mean. We could use macros or functions that add or multiply two ints with an overflow check (perhaps assuming the args are >= 0 and setting the result to a negative number when there's overflow). I've fixed the two list repeat bugs (with one test), added an overflow test for list+list, and also one for tuple+tuple. All backported to 2.2.2. Closing this now (but making a mental note about those overflow macros). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 16:44 Message: Logged In: YES user_id=6380 Fixed 1L<>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 17:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 09:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 05:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Fri Oct 11 22:17:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 14:17:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-622091 ] []*5 core dump Message-ID: Bugs item #622091, was opened at 2002-10-11 17:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622091&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 9 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: []*5 core dump Initial Comment: The repeat overflow check I just added to list and tuple in 2.2.2 and 2.3 breaks for an empty list. Aargh! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622091&group_id=5470 From noreply@sourceforge.net Sat Oct 12 00:41:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 16:41:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-622091 ] []*5 core dump Message-ID: Bugs item #622091, was opened at 2002-10-11 17:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622091&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: []*5 core dump Initial Comment: The repeat overflow check I just added to list and tuple in 2.2.2 and 2.3 breaks for an empty list. Aargh! ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 19:41 Message: Logged In: YES user_id=6380 Fixed in both places. Ouch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622091&group_id=5470 From noreply@sourceforge.net Sat Oct 12 04:36:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 20:36:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-621579 ] test_sax fails on freebsd Message-ID: Bugs item #621579, was opened at 2002-10-10 17:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470 Category: Build >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: test_sax fails on freebsd Initial Comment: test_sax consistently fails on the freebsd system on SF's compile farm. Fred said he'll look into it, so creating this bug report so he doesn't forget . ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-11 23:36 Message: Logged In: YES user_id=3066 Oddly enough, this isn't a real problem. ;-) What's getting tested on that machine is not the xml.sax package provided with Python 2.2.2, but PyXML 0.7.1, which does indeed exhibit that bug (more recent versions of PyXML do not have that one). What's happening is that the default prefix, /usr/local/, already contains a Python 2.2 installation with PyXML 0.7.1 installed, and Python's default sys.path when running from the build directory includes the site-packages of the corresponding installation. I think *that's* a bug, and there's already a SF bug report on the issue. Building Python with a prefix that isn't "contanimated" in this way shows that the pyexpat module is built using the Expat 1.95.2 installed on this system, and the tests pass. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-10 17:26 Message: Logged In: YES user_id=3066 Here's the relevant part of the test output Barry emailed to me earlier. Hopefully it won't get too badly munged by SF. ;-) Failed test_expat_nsattrs_wattr Expected: [('start', ('http://xml.python.org/1', 'abc'), 'abc'), ('start', ('http://xml.python.org/2', 'def'), 'foo:def'), ('end', ('http://xml.python.org/2', 'def'), 'foo:def'), ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'), ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'), ('end', ('http://xml.python.org/1', 'abc'), 'abc')] Received: [('start', (u'http://xml.python.org/1', u'abc'), None), ('start', (u'http://xml.python.org/2', u'def'), None), ('end', (u'http://xml.python.org/2', u'def'), None), ('start', (u'http://xml.python.org/1', u'ghi'), None), ('end', (u'http://xml.python.org/1', u'ghi'), None), ('end', (u'http://xml.python.org/1', u'abc'), None)] Failed test_expat_nsdecl_pair_diff Expected: [('start', ('http://xml.python.org/', 'abc'), 'foo:abc'), ('start', ('http://xml.python.org/', 'def'), 'foo:def'), ('end', ('http://xml.python.org/', 'def'), 'foo:def'), ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'), ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')] Received: [('start', (u'http://xml.python.org/', u'abc'), None), ('start', (u'http://xml.python.org/', u'def'), None), ('end', (u'http://xml.python.org/', u'def'), None), ('start', (u'http://xml.python.org/', u'ghi'), None), ('end', (u'http://xml.python.org/', u'ghi'), None), ('end', (u'http://xml.python.org/', u'abc'), None)] Failed test_expat_nsdecl_pair_same Expected: [('start', ('http://xml.python.org/', 'abc'), 'abc'), ('end', ('http://xml.python.org/', 'abc'), 'abc')] Received: [('start', (u'http://xml.python.org/', u'abc'), None), ('end', (u'http://xml.python.org/', u'abc'), None)] Failed test_expat_nsdecl_single ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621579&group_id=5470 From noreply@sourceforge.net Sat Oct 12 07:04:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 23:04:29 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-622230 ] def object.new_method(self): Message-ID: Feature Requests item #622230, was opened at 2002-10-12 02:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: def object.new_method(self): Initial Comment: I want to be able to create functions inside objects instead of having to do: class x: pass def new_method(self): pass x.new_method = new_method del new_method I want to do: class x: pass def x.new_method(self): pass Why isn't this possible? Wouldn't it be cool? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 From noreply@sourceforge.net Sat Oct 12 07:08:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Oct 2002 23:08:02 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-622230 ] def object.new_method(self): Message-ID: Feature Requests item #622230, was opened at 2002-10-12 02:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: def object.new_method(self): Initial Comment: I want to be able to create functions inside objects instead of having to do: class x: pass def new_method(self): pass x.new_method = new_method del new_method I want to do: class x: pass def x.new_method(self): pass Why isn't this possible? Wouldn't it be cool? ---------------------------------------------------------------------- >Comment By: Dan Parisien (mathematician) Date: 2002-10-12 02:08 Message: Logged In: YES user_id=118203 Repost with attempted better formatting: I don't want to do: class x:     pass def new_method(self):     pass x.new_method = new_method del new_method I want to do: class x:     pass def x.new_method(self):     pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 From noreply@sourceforge.net Sat Oct 12 08:44:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 00:44:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-620630 ] distutils mixed stdin/stdout output Message-ID: Bugs item #620630, was opened at 2002-10-09 06:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: distutils mixed stdin/stdout output Initial Comment: If distutils output is piped to a common logfile, the output is garbled as shown in: http://buildd.debian.org/fetch.php?&pkg=python-numeric&ver=22.0-2&arch=powerpc&stamp=1034115818&file=log&as=raw It's a bit confusing to search errors in the garbled output. It would be nice, if distutils flashes the output buffers on each newline. Not sure how well this shows in the included snippets. gcc-3.2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFSrc/ranlibmodule.c: In function `get_continuous_random': [here in the middle of the line] Src/ranlibmodule.c:47: warning: function declaration isn't a prototype Src/lapack_litemodule.c:649: warning: `lapack_liteError' defined but not used [upto here a compile command, then two other commands succeed, then the error for the link command] /usr/bin/ld: cannot find -lg2c-pic collect2: ld returned 1 exit status [and now the link command:] gcc-3.2 -shared build/temp.linux-ppc-2.3/lapack_litemodule.o -llapack -lblas -lg2c-pic -o build/lib.linux-ppc-2.3/lapack_lite.so error: command 'gcc-3.2' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-10-12 07:44 Message: Logged In: YES user_id=60903 Sure, but then I'll have to change the packaging of about 100 python packages for Debian. The distutils docs talk about "python setup.py", not "python -u setup.py". Can distutils turn on unbuffered output by default? Is there a real performance penalty using distutils with unbuffered output? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:16 Message: Logged In: YES user_id=31392 If you're piping the output to a combined log file, you can use python -u to unbuffer stdout. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 From noreply@sourceforge.net Sat Oct 12 08:52:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 00:52:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-495695 ] webbrowser.py: selection of browser Message-ID: Bugs item #495695, was opened at 2001-12-21 00:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Remind 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: Matthias Klose (doko) Date: 2002-10-12 07:52 Message: Logged In: YES user_id=60903 Setting the "Resolution" from "Invalid" to "Remind", see message from 2002-09-08. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-11 13:13 Message: Logged In: YES user_id=3066 Galeon support has been added in revision 1.33. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-09-08 09:47 Message: Logged In: YES user_id=60903 Attached is a patch, which changes _tryorder to try the text-based browsers first in absence of the DISPLAY environment. No change for the case where BROWSER is set. Should the module take care of the case, where BROWSER is set to i.e. mozilla and you're running on the console? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-01-09 14: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 14: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 13: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 10: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 22: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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495695&group_id=5470 From noreply@sourceforge.net Sat Oct 12 08:53:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 00:53:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-621526 ] docs do not include spec info from PEPs Message-ID: Bugs item #621526, was opened at 2002-10-10 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: docs do not include spec info from PEPs Initial Comment: [please see http://bugs.debian.org/163703] The bug submitter complains, that the information found in accepted PEPs like 252 and 253 cannot be found in the "standard documentation" and proposes, that accepted PEPs are included in the standard documentation. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-10-12 07:53 Message: Logged In: YES user_id=60903 Ok, changed the summary line. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 14:48 Message: Logged In: YES user_id=31392 I don't think PEPs themselves should be included in the documentation, but the relevant spec info should go into the docs in an appropriate location. I think leaving the rationale/discussion part in the PEP is good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 From noreply@sourceforge.net Sat Oct 12 11:12:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 03:12:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2002-10-12 10:12 Message: Logged In: YES user_id=4771 Yes, exactly. I can see a couple of approaches based on values that mean "overflow": 1) there is just one special "overflow" value, e.g. ((size_t)-1), that is returned and propagated by the macros when an overflow is detected. This might be error-prone because if we forget once to use the macros to add a few bytes to the size, this special value will wrap down to a small legal value -- and segfault. 2) same as above, but with a whole range of overflow values. For example, just assume (or decide) that no malloc of more than half the maximum number that fits into a size_t can succeed. We don't need any macro to add a (resonable) constant to a size; we only need a macro for multiplication that -- upon overflow -- returns the first number of the "overflow" range. 3) we compute all sizes with signed integers (int or long), as is currently (erroneously?) done at many places. Any negative integer is regarded as "overflow", but the multiplication macro returns the largest negative integer in case of overflow, so that as above no addition macro is needed. This will require a "multiplication hunt party" :-) Also, approaches 2 and 3 require fixes to ensure that mallocs of sizes in the overflow range always fail, for any of the several implementations of malloc found in the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 21:13 Message: Logged In: YES user_id=6380 OK, I think I see what you mean. We could use macros or functions that add or multiply two ints with an overflow check (perhaps assuming the args are >= 0 and setting the result to a negative number when there's overflow). I've fixed the two list repeat bugs (with one test), added an overflow test for list+list, and also one for tuple+tuple. All backported to 2.2.2. Closing this now (but making a mental note about those overflow macros). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 20:44 Message: Logged In: YES user_id=6380 Fixed 1L<>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 21:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 13:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 09:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Sat Oct 12 12:23:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 04:23:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-622294 ] python-mode: ' or " inside """ Message-ID: Bugs item #622294, was opened at 2002-10-12 11:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622294&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode: ' or " inside """ Initial Comment: [forwarded from http://bugs.debian.org/164423] Inside of a multi-line string delimited by triple-quotes ("""), the syntax highlighting thinks that " or ' terminates the string. This is so bad with ", since they usually come in pairs and syntax highlighting will be correct once the second " is reached. However, the apostrophe is often used in contractions. Once the apostrophe is hit, the string-status of the entire rest of the script is inverted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622294&group_id=5470 From noreply@sourceforge.net Sat Oct 12 12:25:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 04:25:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-622295 ] python-mode: # not ignored in """ Message-ID: Bugs item #622295, was opened at 2002-10-12 11:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622295&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode: # not ignored in """ Initial Comment: [forwarded from http://bugs.debian.org/164424] The syntax highlighting treats the # character as a begin-comment character even when embedded inside a multi-line """ string. It should not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622295&group_id=5470 From noreply@sourceforge.net Sat Oct 12 14:24:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 06:24:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-618623 ] list(xrange(sys.maxint/4)) again Message-ID: Bugs item #618623, was opened at 2002-10-04 12:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Guido van Rossum (gvanrossum) Summary: list(xrange(sys.maxint/4)) again Initial Comment: SF bug #556025 triggers again in the latest 2.2 branch: >>> list(xrange(sys.maxint/4)) Segmentation fault (core dumped) on my Linux box. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-12 09:24 Message: Logged In: YES user_id=6380 I'd like to take this back to a mailing list. Can you repost that to python-dev? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-12 06:12 Message: Logged In: YES user_id=4771 Yes, exactly. I can see a couple of approaches based on values that mean "overflow": 1) there is just one special "overflow" value, e.g. ((size_t)-1), that is returned and propagated by the macros when an overflow is detected. This might be error-prone because if we forget once to use the macros to add a few bytes to the size, this special value will wrap down to a small legal value -- and segfault. 2) same as above, but with a whole range of overflow values. For example, just assume (or decide) that no malloc of more than half the maximum number that fits into a size_t can succeed. We don't need any macro to add a (resonable) constant to a size; we only need a macro for multiplication that -- upon overflow -- returns the first number of the "overflow" range. 3) we compute all sizes with signed integers (int or long), as is currently (erroneously?) done at many places. Any negative integer is regarded as "overflow", but the multiplication macro returns the largest negative integer in case of overflow, so that as above no addition macro is needed. This will require a "multiplication hunt party" :-) Also, approaches 2 and 3 require fixes to ensure that mallocs of sizes in the overflow range always fail, for any of the several implementations of malloc found in the code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 17:13 Message: Logged In: YES user_id=6380 OK, I think I see what you mean. We could use macros or functions that add or multiply two ints with an overflow check (perhaps assuming the args are >= 0 and setting the result to a negative number when there's overflow). I've fixed the two list repeat bugs (with one test), added an overflow test for list+list, and also one for tuple+tuple. All backported to 2.2.2. Closing this now (but making a mental note about those overflow macros). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-11 16:44 Message: Logged In: YES user_id=6380 Fixed 1L<>> '%2147483647d' % -123 Segmentation fault >>> 1L<<2147483647 SystemError: NULL object passed to PyObject_InitVar ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 17:07 Message: Logged In: YES user_id=21627 Good. I suggest we take no action for 2.2. For the other bugs you found, would you like to propose a patch? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2002-10-05 09:41 Message: Logged In: YES user_id=4771 Right, the bug doesn't show up on my SuSE 7 either, but only on an old Mandrake box. I found out that it is caused by a bug in malloc(). Any malloc(n) with n greater than (1<<31)-12 will pretend it succeeded, but actually only allocate a few bytes, hence the immediately following segmentation fault. As it seems to be fixed in recent versions of the libc I suggest to ignore this problem. However, there are other overflow bugs in listobject.c which are not malloc()'s fault. Would you like me to go over the whole code in detail and submit a patch? Here are a couple of examples: >>> (sys.maxint/16+1) * range(16) SystemError: Objects/listobject.c:63: bad argument to internal function >>> (sys.maxint/2+1) * range(16) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-05 05:57 Message: Logged In: YES user_id=21627 I can't reproduce this on SuSE 8.1. Can you analyse this in more detail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618623&group_id=5470 From noreply@sourceforge.net Sat Oct 12 15:15:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 07:15:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-621519 ] broken link in html reference manual Message-ID: Bugs item #621519, was opened at 2002-10-10 15:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621519&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: broken link in html reference manual Initial Comment: Debian report #161907 (seen as well at http://www.python.org/doc/current/ref/exceptions.html) Hello, I found a broken link in the HTML version of the Python Reference Manual. The page at file:///usr/share/doc/python2.2/html/ref/exceptions.html contains (near the bottom, the label is "7.4") a link to file:///usr/share/doc/python2.2/html/ref/node86.html#try This file does not exist. The correct name seems to be "try.html". I hope this helps, Jochen ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-12 10:15 Message: Logged In: YES user_id=3066 Closing since this is a duplicate, as Neal says. Neal: I suspect there's a problem in the way we do file renaming in Doc/tools/node2label.pl, but it's nothing obvious (I've looked for this one a few times). That script relies on some data structures that get saved by latex2html; I don't think it's too hard to see how those structures are laid out. Start by running make in the Doc/ directory; when that completes all the relevant intermediate files should be present. The node2label.pl script will tell you which files to look at ("labels.pl" or "intlabels.pl"; don't remember which offhand). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 18:30 Message: Logged In: YES user_id=33168 This is a duplicate of 217195 - http://python.org/sf/217195. Fred, it appears the ref is fine in the .tex, is there some place I could look to fix this problem? I don't know how to build the docs at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621519&group_id=5470 From noreply@sourceforge.net Sat Oct 12 16:04:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 08:04:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-614821 ] broken link in documentation Message-ID: Bugs item #614821, was opened at 2002-09-26 02:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614821&group_id=5470 Category: Documentation Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: broken link in documentation Initial Comment: Just checking in my referer log, and got a number of failed requests coming from: http://www.python.org/doc/current/lib/other-gui-packages.html The correct URL for PyGTK is http://www.daa.com.au/~james/pygtk/ rather than http://www.daa.com.au/james/pytgk/ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-12 11:04 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/tkinter.tex 1.15 and 1.10.6.5. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 18:01 Message: Logged In: YES user_id=33168 There is a \~ (backslash tilde) in the file already. Fred, do tildes need to be escaped or is there a different way to escape them? The file is Doc/lib/tkinter.tex, lines 1822 - 1830. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=614821&group_id=5470 From noreply@sourceforge.net Sat Oct 12 16:12:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 08:12:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-604716 ] faster [None]*n or []*n Message-ID: Bugs item #604716, was opened at 2002-09-04 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: faster [None]*n or []*n Initial Comment: This is a suggestion to speed up multiplying a list by an integer, in the case where the length of the list is 0 or 1. currently there is a lot of overhead in the loop for these cases. The current loop ( in list_repeat, in listobject.c) : p = np->ob_item; for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } return (PyObject *) np; Suggested ( where Py_INCREF_N(o,n) bumps the refcount of 'o' by n): p = np->ob_item; if( a->ob_size <= 1 ){ if( a->ob_size ){ // is 1 Pyobject *a0 = a->ob_item[0]; for (i = 0; i < n; i++) { *p++ = a0; } Py_INCREF_N(a0,n); } }else{ for (i = 0; i < n; i++) { for (j = 0; j < a->ob_size; j++) { *p = a->ob_item[j]; Py_INCREF(*p); p++; } } } return (PyObject *) np; You could also do special cases for len=2, etc (with *p++ = a0; *p++ = a1; inside) but len=1 is a common case, with things like [None]*1000 used to create lists. The best approach in general is to check if the list being replicated is sufficiently smaller than the replication count; and if so, use a different set of loops nested in the other order, so that the outer loop runs less often. With the inverted loop case, you have 'a->ob_size' calls to Py_INCREF_N instead of 'a->ob_size*n' calls to Py_INCREF. Exact same comments apply to tuplerepeat(). If any interest, I will code this and test it. ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2002-10-12 11:12 Message: Logged In: YES user_id=292741 Sure, the loop inversion is not a big deal. There are two slightly larger issues, though: (1) O(n) time for []*n seems worth fixing; I noticed Guido was just in there adding a size check, and bumping into the [..]*0 case (descr. in #622091 as []*5 ), so another little edit won't hurt right? I suggest changing size = a->ob_size * n; if (n && size/n != a->ob_size) return PyErr_NoMemory(); to size = a->ob_size * n; if( size == 0 ) return PyList_New(0); if (size/n != a->ob_size) return PyErr_NoMemory(); which is hopefully correct by inductive inspection :-) (2) If there is any merit seen in introducing Py_INCREF_N to object.h for future use, this seems as good a place as any to break ground. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-04 16:16 Message: Logged In: YES user_id=80475 It's starting to look as if any sort of optimization effort will take more human time to create, test, and review than it could ever save in computer time. Can this be closed? ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-12 17:13 Message: Logged In: YES user_id=292741 OK, i'll try that when I have time. The problem is, you can't do [None]*1000000 over and over again for 10 seconds unless you also destroy the lists, there isn't enough RAM - and I was trying not to count the dispose time, which of course is also dependent on the list length. I was calling calling clock() immediately before and after the operation, and accumulating the differences, thus excluding the rest of the loop with the list delete. any uncertainty in clock() should in principle average out over a lot of reps. For what it's worth, the results were reasonably repeatable from run to run (maybe 5%) and very linear with respect to changing the '*1000000' factor. I know i'm effectively timing one call to clock() as part of the timed code; but that won't change with the list size and can thus be factored out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 12:43 Message: Logged In: YES user_id=21627 Please don't invoke clock() twice per iteration. The standard timing procedure is iterations = [None] * niter start = clock() for i in iterations: actions_to_time total = clock() - start That way, you don't measure the time it takes to create the range object. Also, don't trust any measurements that have a total time of less then 10s (running it for a minute is even better). With this algorithm, please re-report the two totals, and the number of iterations. Run it several times in a row, to see how results vary. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 19:10 Message: Logged In: YES user_id=292741 using this test code, and changing the 1000000, I have found that it adds an additional 40 nsec for each additional copy of the None. This doesn't change noticeably when I add the 'improvement'. If I change it to []*whatever, then the old implementation needs 5 ns extra for each non-copy (and the new one isn't sensitive). This is telling me that most of the time in the [None]*lots is in the PyList_New() to get the list. So I went and made a variant of PyList_New which doesn't clear the list, and found that [None]*1000000 takes 22msec instead of the 40 it used to take. This doesn't make too much sense, looking at the code; maybe cache effects. Time to go home now... ------------------------- def timeit(): from time import clock t0 = clock() tin = 0 niter = 50 for i in range(niter): ta,p,tb = clock(),[None]*1000000,clock() tin += tb-ta p = 0 # deallocate list t0 = clock()-t0 print "avg. time = ", tin/niter print "avg. overhead = ", t0/niter timeit() --------------------- ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 15:16 Message: Logged In: YES user_id=80475 Yes, I looked at the all-at-once memcpy approach but found that MVC++'s memcpy() was too smart and would not use the buffer overlap as intended. This is a dead-end. Using memcpy() in a loop as I suggested will work fine. Neal implemented a number of micro-optimizations using this and/or memchr(). You've already hit on the common case and best speed-up by special casing length one and by py_incref_n. Go for it. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2002-09-06 14:41 Message: Logged In: YES user_id=292741 [ sound effects: can opener, worms... ] ;-) Use of memcpy/memset is a whole other issue- see below What you've got there doesn't help for the case I mention. If you do []*100000, you get 100000 calls to memcpy with size = 0, and if you do [None]*100000, 100000 calls to memcpy with size = 4; this could easily wind up being even slower. The point is to reduce the number of times the inner loop quits and the outer loop runs; the actual code in the inner loop will run the same number of times regardless (although *p = regvar is faster than *p = ptr->a[j] ); it's the loop overhead (instruction queue flushes, etc) that make a difference here. Bear in mind too that 'j < a->ob_size' will load a->ob_size on each loop, if the compiler can't be sure you didn't write it via *p [yes i''ve spent too much time looking at C compiler output. real-time DSP applications mostly]. Many compilers do intrinsic memcpy so that there's no call, but since the length of the copy is not fixed, code still needs to be generated to test the length, and you wind up being no better than the original for short source lists. Regarding the use of memcpy/memset in general; these could be applied in a lot of cases - making a list slice, filling a new list with null's etc - and on some machines they make a big difference to the speed of the operation. Compared to the time spent later working on that list, it may not show up much in the end. Having said that, I've done some python apps which process, say, 20Mbytes of binary floating-point data in about 12 seconds, by avoiding any python looping ( using Numeric and image file read/writes). In this kind of thing, a faster slice copy can make difference. I'm assuming the programmer would rather not have the marginal speedup of these routines, if it poses even a small possibility of creating portability issues on some weird machine, and this is a pretty wise policy on a project of this nature. I suspect any machine where memcpy doesn't work in this context would also fail to work with python's polymorphism and general memory management, but whatever. A really good way to make a lot of copies of a small list is to make the first copy, then do a single memcpy( p, p+size, (n-1)*size * sizeof(*p) ) which 'rolls' the same memory over and over. No loops (except within memcpy and the assumption is that that one is as good as it gets). But this may be even less portable than the other uses of memcpy, because it makes assumptions about how memcpy handles overlapped transfers. E.g., machines with a lot of registers could do a bunch of reads and a bunch of writes to help out the cache, thus breaking this for small input lists. And yes, I'll report some speedup results when I have some. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-06 14:38 Message: Logged In: YES user_id=80475 There was a typo in my code fragment. It should have read: memcpy(p + i*n, a->ob_item, a->ob_size * sizeof (PyObject *)); The memcpy speeds up cases where there are many items in the list. It is actually slower for a list of length one which should still be special cased as the OP suggested. Also, his idea for adding Py_INCREF_N is great. It can be used throughout python. Since Py_INCREF has lots of macro magic for updating debug statistics, the OP's idea may have to be implemented as a function. I think there is interest in the OP's ideas and that he should go-ahead and develop a tested patch along with timing statistics. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 05:53 Message: Logged In: YES user_id=21627 Can you report what speed-up you get, for what example? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-04 21:45 Message: Logged In: YES user_id=80475 Here's a faster approach that doesn't involve a special case: for (i = 0; i < n; i++) memcpy(p + i*n, p, size); for (j = 0; j < a->ob_size; j++){ Py_INCREF_N(*p, n); p++; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=604716&group_id=5470 From noreply@sourceforge.net Sat Oct 12 17:33:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 09:33:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-622294 ] python-mode: ' or " inside """ Message-ID: Bugs item #622294, was opened at 2002-10-12 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622294&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) >Summary: python-mode: ' or " inside """ Initial Comment: [forwarded from http://bugs.debian.org/164423] Inside of a multi-line string delimited by triple-quotes ("""), the syntax highlighting thinks that " or ' terminates the string. This is so bad with ", since they usually come in pairs and syntax highlighting will be correct once the second " is reached. However, the apostrophe is often used in contractions. Once the apostrophe is hit, the string-status of the entire rest of the script is inverted. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-12 12:33 Message: Logged In: YES user_id=12800 This is caused by a limitation in Emacs. See the FAQ http://www.python.org/emacs/python-mode/faq.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622294&group_id=5470 From noreply@sourceforge.net Sat Oct 12 17:57:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 09:57:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-622295 ] python-mode: # not ignored in """ Message-ID: Bugs item #622295, was opened at 2002-10-12 07:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622295&group_id=5470 >Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) >Summary: python-mode: # not ignored in """ Initial Comment: [forwarded from http://bugs.debian.org/164424] The syntax highlighting treats the # character as a begin-comment character even when embedded inside a multi-line """ string. It should not. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-12 12:57 Message: Logged In: YES user_id=12800 Works for me in XEmacs 21.4 and Emacs 21.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622295&group_id=5470 From noreply@sourceforge.net Sun Oct 13 07:14:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 12 Oct 2002 23:14:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-622295 ] python-mode: # not ignored in """ Message-ID: Bugs item #622295, was opened at 2002-10-12 07:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622295&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) >Summary: python-mode: # not ignored in """ Initial Comment: [forwarded from http://bugs.debian.org/164424] The syntax highlighting treats the # character as a begin-comment character even when embedded inside a multi-line """ string. It should not. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-13 02:14 Message: Logged In: YES user_id=12800 Works for me in XEmacs 21.4 and Emacs 21.2. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-12 12:57 Message: Logged In: YES user_id=12800 Works for me in XEmacs 21.4 and Emacs 21.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622295&group_id=5470 From noreply@sourceforge.net Sun Oct 13 12:05:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 04:05:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind Message-ID: Bugs item #621548, was opened at 2002-10-10 22:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jamin W. Collins (jamincollins) Assigned to: Nobody/Anonymous (nobody) Summary: Numerous defunct threads left behind Initial Comment: I originally noticed this problem with Debian's OfflineIMAP package and filed a report there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369 The short of it is that when running offlineimap for an extended period of time it will eventually leave a large number of defunct threads behind that eventually use up all available system processes. Killing the original offlineimap thread clears the problem for a while. The Debian maintainer of OfflineIMAP referred this over to the python maintainer, who in turn has asked (as you can see from the link above) that I file a report here. If there is any more information I can provide (beyond that in the Debian case already) please let me know. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:05 Message: Logged In: YES user_id=21627 The analysis that this is a Python bug is most likely wrong. You write > a number of defunct/zombie processes are spawned. then John Goerzen writes > It is likely, in any case, that this is a bug in Python itself. The > OfflineIMAP program does not fork However, John later points out that there are many threads used in this package. Please understand that threads show up as processes in Linux ps(1). IOW, what you are seeing are the many threads, not any additional processes. It appears that the system is waiting for somebody to call pthread_join. This should not be necessary, since Python invokes pthread_detach for all of its threads. So if the system does not reclaim terminated threads, it seems there is a bug in your C library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470 From noreply@sourceforge.net Sun Oct 13 12:21:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 04:21:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-621523 ] sizeof(struct stat) changes Message-ID: Bugs item #621523, was opened at 2002-10-10 21:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: sizeof(struct stat) changes Initial Comment: Including Python.h changes sizeof(struct stat): ralf@gandalf:~$ cat t.c #ifdef USE_PYTHON #include #endif #include main() { printf ("sizeof=%d\n", sizeof(struct stat)); } ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2 -DUSE_PYTHON && ./a.out sizeof=96 ralf@gandalf:~$ gcc t.c && ./a.out sizeof=88 ralf@gandalf:~$ uname -a Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002 i686 unknown rechecked with gcc-3.2 and current HEAD. Platform tests is Debian woody and Debian unstable. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:21 Message: Logged In: YES user_id=21627 Adding documentation is certainly possible, however: At what places did you look for documentation before writing your module? Changing the Python configuration process is not possible: Python.h depends on various system headers. When those headers get included, we *must* have the LFS support enabled, because it is not possible to include the system headers a second time later. Not including system headers is also not possible, since Python.h provides API that relies on system headers, e.g. functions taking FILE*. I think this is really something for the C library to solve, which should arrange for linker warnings if you try to combine LFS objects with non-LFS objects. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2002-10-11 13:02 Message: Logged In: YES user_id=17929 Well, at least it was a problem for me. I built a shared C++ library, where one of the classes had a private member of type struct stat and a virtual destructor, and had some subclasses of this class. Then I built a python module, linking against that library. When deleting those subclasses I got segfaults and it did take me pretty long to find out why this was happening (assuming at first that I had buffer over/underruns, then suspecting the compiler...). I essentially removed all of the code from the library and it was still segfaulting. I was really surprised when I changed that struct stat to a character array of same size... The problem here is within linux, if I would compile a standalone C++ program with largefile support, linking against that library, I would get the same results. But then at least I would have known, that I didn't use standard options to compile it. A solution for this problem would be to add a warning to python's documentation, or maybe move some of those defines from pyconfig.h to a private header file (assuming here that none of the structs declared in Python.h depend on struct stat. If they did, including sys/stat.h before Python.h might also be a bad idea). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 00:22 Message: Logged In: YES user_id=33168 The problem is that Python is built with large file support. I'm running RedHat and your example works the same for me. It appears that _LARGEFILE64_SOURCE (_LARGEFILE_SOURCE on my system) is defined in pyconfig.h. So __USE_FILE_OFFSET64 gets defined in /usr/include/features.h. Python can be built without large file support, in which case the size will not change. Is this really a problem? Can it be solved by removing large file support from python? Can you include before including Python.h to solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 From noreply@sourceforge.net Sun Oct 13 14:02:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 06:02:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 09:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-10-13 08:02 Message: Logged In: YES user_id=2772 Don't shared modules need the extension .pyd instead of .dll? Is sys.path[0] some absolute directory (the one containing idle.py, for instance) instead of '.'? Is there a way to run idle with -v so that it lists directories and files it tries to import as modules? ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-07 16:53 Message: Logged In: YES user_id=271417 I should have noted that 'import' _does_ work to a degree - 'import os' worked. The '_example.dll' that I am trying to import is the 'shapes' example that is distributed with SWIG 1.3.15, and should import without any trouble. It does import just fine from the command line version of Python, but not from Idle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 From noreply@sourceforge.net Sun Oct 13 15:08:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 07:08:28 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-619222 ] os.listdir-alike that includes file type Message-ID: Feature Requests item #619222, was opened at 2002-10-06 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir-alike that includes file type Initial Comment: I propose to add two new functions, say os.listdirtypes and os.llistdirtypes. These would be similar to os.listdir except they would return a list of tuples (filename, filetype). This would have the advantage that on oses that support the d_type entry in the dirent struct the type could be calculated without extra calls and harddrive reading. Even on non-supporting os/filesystems, it could emulate it with a call to stat/lstat in the func, still saving some work of calling stat and interpreting its result in python code or using os.path.isX. Filetype would indicate wether the entry was a file, directory, link, fifo, etc. This could either be a char (like ls -l gives) ('-', 'd', 'l', 'p', etc), or some sort of constant (os.DT_REG, os.DT_DIR, os.DT_LNK, os.DT_FIFO, etc). Personally I think the string method is simpler and easier, though some (non-*ix) people may be confused by '-' being file rather than 'f'. (Of course, you could change that, but then *ix users would be confused ;) listdirtypes would be equivalent to using stat, ie. symlinks would be followed when determining types, and llistdirtypes would be like lstat so symlinks would be indicated as 'l'. An app I'm working on right now that reads in a directory tree on startup got about a 2.2x speedup when I implemented this as an extension module, and about 1.6x speedup when I tested it without d_type support. (The module was written using Pyrex, so its not a candidate for inclusion itself, but I would be willing to work on a C implementation if this idea is accepted..) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 16:08 Message: Logged In: YES user_id=21627 I'm in favour of exposing more information received from readdir. I'm not sure whether adding new functions is the right API, perhaps adding a flag to the existing listdir is sufficient. I don't think listdir should perform stat calls itself; if the system has some information available, fine, if it doesn't, return nothing. What is the proposed difference between listdirtypes and llistdirtypes? On the return type of the "verbose" listdir, I think it should return structs with named fields, such as d_ino, d_name, and d_type. Callers can then find out themselves what information they got, and augment this with information from stat that they also need. In particular, d_type should be returned as presented in the system, since it might have slight semantic difference to what os.stat would tell about the file. This should extend to other systems as well. E.g. on Windows, it is possible to learn the modification times from listdir, with no extra overhead. There should also be a way to use this with os.path.walk. So, in short, I'm in favour of this idea. Would you volunteer to write a PEP, and provide the Unix implementation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470 From noreply@sourceforge.net Sun Oct 13 15:14:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 07:14:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-620179 ] __ipow__ broken for new-style classes Message-ID: Bugs item #620179, was opened at 2002-10-08 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Alexander Schmolck (aschmolck) >Assigned to: Guido van Rossum (gvanrossum) >Summary: __ipow__ broken for new-style classes Initial Comment: class NewKlass(object): def __ipow__(self, i): self._ipow = i return self obj = NewKlass() obj **= 1 TypeError: __ipow__() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-13 10:14 Message: Logged In: YES user_id=6380 Whoops, you're right. This was there since 2.2. Unfortunately "fixing" this means broken code that would have worked before, so I won't fix it in 2.2.2; I'll fix it in 2.3 though. Workaround; declare __ipow__ with an *optional* dummy extra argument, defaulting to None (it will only be called with None in that position anyway): def __ipow__(self, i, arg=None): ... This provides you with forward compatibility in 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 From noreply@sourceforge.net Sun Oct 13 15:56:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 07:56:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-620364 ] core setup.py fails on Windows Message-ID: Bugs item #620364, was opened at 2002-10-08 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None >Priority: 1 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py fails on Windows Initial Comment: 1. Extract Python-2.2.2b1.tgz into a directory (E:\dev\python\src in this case). 2. Run 'python setup.py build' in the source root directory. 3. Witness the bug (output shown at the bottom of this message). The problem is that on line 81 of setup.py, the srcdir is set to None rather than a meaningful directory name (distutils.sysconfig.get_config_vars('srcdir') returns [None]). The traceback below arises on line 84, when None is passed as an argument to os.path.join. My operating system is Windows 2000, and I have MSVC 6 installed. The compiler is configured properly; I've built many other distutils-ified extensions without a hitch. This bug arises regardless of whether the Python-2.2.1 version of distutils or the Python-2.2.2b1 version of distutils is used (both versions are labeled as distutils 1.0.3). To generate the traceback shown below, I used the official Windows binary distribution of Python-2.2.1 (that is, the 'python' in 'python setup.py build' referred to Python-2.2.1), but the results are the same if I compile Python-2.2.2b1 by other means and then attempt to use the resulting executable to run its own distutils setup script. ---------------------------------------------------------- E:\dev\python\src\Python-2.2.2b1>python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 792, in ? main() File "setup.py", line 787, in main scripts = ['Tools/scripts/pydoc'] File "e:\dev\python\core\lib\distutils\core.py", line 138, in setup dist.run_commands() File "e:\dev\python\core\lib\distutils\dist.py", line 893, in run_commands self.run_command(cmd) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build.py", line 107, in run self.run_command(cmd_name) File "e:\dev\python\core\lib\distutils\cmd.py", line 330, in run_command self.distribution.run_command(command) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build_ext.py", line 256, in run self.build_extensions() File "setup.py", line 84, in build_extensions moddir = os.path.join(os.getcwd(), srcdir, 'Modules') File "E:\dev\python\core\Lib\ntpath.py", line 49, in join elif isabs(b): File "E:\dev\python\core\Lib\ntpath.py", line 35, in isabs s = splitdrive(s)[1] File "E:\dev\python\core\Lib\ntpath.py", line 101, in splitdrive if p[1:2] == ':': TypeError: unsubscriptable object ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-13 10:56 Message: Logged In: YES user_id=6380 Please submit an actual patch in context diff format. I'd be happy to fix this in 2.3 but I've lowered the priority appropriately. ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2002-10-09 08:23 Message: Logged In: YES user_id=414645 > This is by design, the Python distribution itself is not build > using setup.py, except for Cygwin targets. I can accept that readily enough, but shouldn't setup.py raise a more meaningful error message, instead of gracelessly dumping a traceback that occurs when it tries to pass an erroneous value (None) to os.path.join? The current behavior may be by design, but to the uninitiated, it *very* strongly resembles a bug. Why not test srcdir (created on line 81 in the current setup.py) to see if it's a meaningful value, and raise an informative error message if not? Like this (line width ridiculously constrained for the sake of SF's forum): ################################################## (srcdir,) = sysconfig.get_config_vars('srcdir') if not srcDir: raise EnvironmentError("The system configuration" " variable 'srcdir' is not defined, so this" " setup script cannot continue. This error" " probably arose because this setup script" " is only designed to run in the Cygwin" " environment, yet you are attempting to" " run it elsewhere." ) ################################################## ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 02:27 Message: Logged In: YES user_id=21627 This is by design, the Python distribution itself is not build using setup.py, except for Cygwin targets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 From noreply@sourceforge.net Sun Oct 13 16:47:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 08:47:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerson Kurz (gersonkurz) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- >Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-13 15:47 Message: Logged In: YES user_id=367261 It is the latest version of cygwin I know of, the cygwin1.dll is dated 2002-07-06 02:16. uname -a says CYGWIN_NT-5.0 DREIZEHN 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown so I guess its the 1.3.12 you mentioned. I can reproduce the crash using the following very simple script b = {} for i in range(900000): b[i] = [0] * 60 when I use range(900000), I get a crash. When I use range (800000), I see this Traceback (most recent call last): File "test2.py", line 3, in ? b[i] = [0] * 60 and then a crash. When I use (500000), it works. It smells like some 256mb limit or something; the memory for the process goes up to 264.000k which comes close, and then crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 01:43 Message: Logged In: YES user_id=33168 Do you know where python crashed? My guess was after a failed malloc. I tried testing this, but I don't have enough memory/cpu/patience to wait for loading such a large file. Can you make the test case smaller? What is the minimum size that still causes the seg fault? What version of cygwin? There is a known malloc problem in 1.3.12, see http://sources.redhat.com/ml/newlib/2002/msg00369.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Sun Oct 13 20:57:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 12:57:16 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-619222 ] os.listdir-alike that includes file type Message-ID: Feature Requests item #619222, was opened at 2002-10-06 05:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir-alike that includes file type Initial Comment: I propose to add two new functions, say os.listdirtypes and os.llistdirtypes. These would be similar to os.listdir except they would return a list of tuples (filename, filetype). This would have the advantage that on oses that support the d_type entry in the dirent struct the type could be calculated without extra calls and harddrive reading. Even on non-supporting os/filesystems, it could emulate it with a call to stat/lstat in the func, still saving some work of calling stat and interpreting its result in python code or using os.path.isX. Filetype would indicate wether the entry was a file, directory, link, fifo, etc. This could either be a char (like ls -l gives) ('-', 'd', 'l', 'p', etc), or some sort of constant (os.DT_REG, os.DT_DIR, os.DT_LNK, os.DT_FIFO, etc). Personally I think the string method is simpler and easier, though some (non-*ix) people may be confused by '-' being file rather than 'f'. (Of course, you could change that, but then *ix users would be confused ;) listdirtypes would be equivalent to using stat, ie. symlinks would be followed when determining types, and llistdirtypes would be like lstat so symlinks would be indicated as 'l'. An app I'm working on right now that reads in a directory tree on startup got about a 2.2x speedup when I implemented this as an extension module, and about 1.6x speedup when I tested it without d_type support. (The module was written using Pyrex, so its not a candidate for inclusion itself, but I would be willing to work on a C implementation if this idea is accepted..) ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2002-10-13 12:57 Message: Logged In: YES user_id=65253 Adding a flag to the existing listdir as opposed to adding more functions would be fine I think. There are two reasons I suggest adding the stat calls in listdir. The first is purely practical, and that is even without a filesystem that supports the d_type field, you can still get a decent speed up merely by performing the stat call in C rather than python. The second is from a usability point of view. If listdir would not do the stat for you, your code would always have to have a seperate case to handle the non-d_type using filesystems, so it would not really make listdir any easier to use, whereas if listdir did the stat itself, you could simplify a huge amount of code out there that always follows an os.listdir by os.stat or os.path.isX. Perhaps the d_type field could be returned verbatim, but a seperate field could be added that, if d_type was something useful would just be set by that, or otherwise would be set by a call to stat, that way you could still see if you really wanted to whether the filesystem actually gave you the d_type. The difference between listdirtypes and llistdirtypes is just like the difference between os.stat and os.lstat, that is in the case of symlinks the first will return the data of the linked-to file while the second will return the data of the symlink it self. Again, this is mostly for user convenience. As for os.path.walk, a flag could be added to that which would replace the "names" argument with the same return type as the new verbose-listdir. Sure, I'll volunteer. I'll start reading up on the PEP process. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 07:08 Message: Logged In: YES user_id=21627 I'm in favour of exposing more information received from readdir. I'm not sure whether adding new functions is the right API, perhaps adding a flag to the existing listdir is sufficient. I don't think listdir should perform stat calls itself; if the system has some information available, fine, if it doesn't, return nothing. What is the proposed difference between listdirtypes and llistdirtypes? On the return type of the "verbose" listdir, I think it should return structs with named fields, such as d_ino, d_name, and d_type. Callers can then find out themselves what information they got, and augment this with information from stat that they also need. In particular, d_type should be returned as presented in the system, since it might have slight semantic difference to what os.stat would tell about the file. This should extend to other systems as well. E.g. on Windows, it is possible to learn the modification times from listdir, with no extra overhead. There should also be a way to use this with os.path.walk. So, in short, I'm in favour of this idea. Would you volunteer to write a PEP, and provide the Unix implementation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=619222&group_id=5470 From noreply@sourceforge.net Sun Oct 13 21:04:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 13:04:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-620364 ] core setup.py fails on Windows Message-ID: Bugs item #620364, was opened at 2002-10-08 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 1 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py fails on Windows Initial Comment: 1. Extract Python-2.2.2b1.tgz into a directory (E:\dev\python\src in this case). 2. Run 'python setup.py build' in the source root directory. 3. Witness the bug (output shown at the bottom of this message). The problem is that on line 81 of setup.py, the srcdir is set to None rather than a meaningful directory name (distutils.sysconfig.get_config_vars('srcdir') returns [None]). The traceback below arises on line 84, when None is passed as an argument to os.path.join. My operating system is Windows 2000, and I have MSVC 6 installed. The compiler is configured properly; I've built many other distutils-ified extensions without a hitch. This bug arises regardless of whether the Python-2.2.1 version of distutils or the Python-2.2.2b1 version of distutils is used (both versions are labeled as distutils 1.0.3). To generate the traceback shown below, I used the official Windows binary distribution of Python-2.2.1 (that is, the 'python' in 'python setup.py build' referred to Python-2.2.1), but the results are the same if I compile Python-2.2.2b1 by other means and then attempt to use the resulting executable to run its own distutils setup script. ---------------------------------------------------------- E:\dev\python\src\Python-2.2.2b1>python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 792, in ? main() File "setup.py", line 787, in main scripts = ['Tools/scripts/pydoc'] File "e:\dev\python\core\lib\distutils\core.py", line 138, in setup dist.run_commands() File "e:\dev\python\core\lib\distutils\dist.py", line 893, in run_commands self.run_command(cmd) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build.py", line 107, in run self.run_command(cmd_name) File "e:\dev\python\core\lib\distutils\cmd.py", line 330, in run_command self.distribution.run_command(command) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build_ext.py", line 256, in run self.build_extensions() File "setup.py", line 84, in build_extensions moddir = os.path.join(os.getcwd(), srcdir, 'Modules') File "E:\dev\python\core\Lib\ntpath.py", line 49, in join elif isabs(b): File "E:\dev\python\core\Lib\ntpath.py", line 35, in isabs s = splitdrive(s)[1] File "E:\dev\python\core\Lib\ntpath.py", line 101, in splitdrive if p[1:2] == ':': TypeError: unsubscriptable object ---------------------------------------------------------------------- >Comment By: David Rushby (woodsplitter) Date: 2002-10-13 16:04 Message: Logged In: YES user_id=414645 Done: http://sourceforge.net/tracker/index.php? func=detail&aid=622704&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-13 10:56 Message: Logged In: YES user_id=6380 Please submit an actual patch in context diff format. I'd be happy to fix this in 2.3 but I've lowered the priority appropriately. ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2002-10-09 08:23 Message: Logged In: YES user_id=414645 > This is by design, the Python distribution itself is not build > using setup.py, except for Cygwin targets. I can accept that readily enough, but shouldn't setup.py raise a more meaningful error message, instead of gracelessly dumping a traceback that occurs when it tries to pass an erroneous value (None) to os.path.join? The current behavior may be by design, but to the uninitiated, it *very* strongly resembles a bug. Why not test srcdir (created on line 81 in the current setup.py) to see if it's a meaningful value, and raise an informative error message if not? Like this (line width ridiculously constrained for the sake of SF's forum): ################################################## (srcdir,) = sysconfig.get_config_vars('srcdir') if not srcDir: raise EnvironmentError("The system configuration" " variable 'srcdir' is not defined, so this" " setup script cannot continue. This error" " probably arose because this setup script" " is only designed to run in the Cygwin" " environment, yet you are attempting to" " run it elsewhere." ) ################################################## ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 02:27 Message: Logged In: YES user_id=21627 This is by design, the Python distribution itself is not build using setup.py, except for Cygwin targets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 From noreply@sourceforge.net Mon Oct 14 05:07:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 21:07:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-622831 ] textwrap fails on unicode using defaults Message-ID: Bugs item #622831, was opened at 2002-10-13 20:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622831&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Nobody/Anonymous (nobody) Summary: textwrap fails on unicode using defaults Initial Comment: I don't know if this is a module bug or a documentation bug. I'm using the documentation from the manual on python.org. >>> x = TextWrapper() >>> x.wrap(u'abcd') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/textwrap.py", line 239, in wrap text = self._munge_whitespace(text) File "/usr/local/lib/python2.3/textwrap.py", line 99, in _munge_whitespace text = text.translate(self.whitespace_trans) TypeError: character mapping must return integer, None or unicode If you do x.replace_whitespace = True, then it will wrap the text. So either whitespace replacement needs to be fixed, or the docs need to be updated to note that you have to set replace_whitespace to false if you want to wrap unicode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622831&group_id=5470 From noreply@sourceforge.net Mon Oct 14 06:00:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Oct 2002 22:00:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-622849 ] inconsistent results of leading whitespace in textwrap input Message-ID: Bugs item #622849, was opened at 2002-10-13 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent results of leading whitespace in textwrap input Initial Comment: >>> x = TextWrapper() >>> x.wrap('This is a sentence that will not wrap') ['This is a sentence that will not wrap'] >>> x.wrap(' This is a sentence that will not wrap') [' This is a sentence that will not wrap'] >>> x.wrap('This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] >>> x.wrap(' This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] To me, this looks like a bug. It violates POLA, anyway (took me a while to figure out why one paragraph and only one paragraph in my output was indented more than the rest). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 From noreply@sourceforge.net Mon Oct 14 11:43:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 03:43:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-622953 ] import order changes with freeze Message-ID: Bugs item #622953, was opened at 2002-10-14 12:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Pim Buurman (pimbuur) Assigned to: Nobody/Anonymous (nobody) Summary: import order changes with freeze Initial Comment: When you have simple .py files in packages, when you do: from mainp.subp import submod both mainp and mainp.subp are imported, i.e. mainp.__init__.py and mainp.subp.__init__.py are interpreted. If you have frozen the package (Tools/freeze), mainp.subp.submod is found at once, and mainp and mainp.subp are not imported. This breaks the code for more complex situations, where the __init__ does contain vital initialization code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 From noreply@sourceforge.net Mon Oct 14 11:49:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 03:49:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-599679 ] CRAM-MD5 module Message-ID: Bugs item #599679, was opened at 2002-08-25 03:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Piers Lauder (pierslauder) Summary: CRAM-MD5 module Initial Comment: [Taken from http://bugs.debian.org/154283] A request to provide CRAM-MD5 authentification (in imaplib). ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2002-10-14 20:49 Message: Logged In: YES user_id=196212 The support is already present for doing CRAM-MD5 authentication. For instance the following code should work: def authenticator(challenge): import hmac return User + " " + hamc.HMAC(Password, challenge).hexdigest() M = imaplib.IMAP4(host) M.authenticate('CRAM-MD5', authenticator) Let me know if it works for you, and i'll consider adding the code to IMAP4.login to try CRAM-MD5 automatically provided it appears in the server capabilities response. (I'm reluctant to do so because similar code in smtplib failed to work for some SMTP server versions and broke login completely.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-04 05:42 Message: Logged In: YES user_id=6380 Assigning to Piers Lauder, who supports the imaplib module. But it would be nice if you submitted a patch. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-25 22:31 Message: Logged In: YES user_id=163326 Well, the necessary code could probably be found in smtplib.py. Perhaps it only needs to be adapted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599679&group_id=5470 From noreply@sourceforge.net Mon Oct 14 13:21:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 05:21:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-585882 ] re.finditer Message-ID: Bugs item #585882, was opened at 2002-07-24 08:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585882&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer Initial Comment: There is an inconsistency between re and sre: $ python Python 2.2.1 (#1, Apr 9 2002, 13:10:27) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.finditer('r+?','library') Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'finditer' whereas >>> import sre >>> sre.finditer('r+?','library') works. I also reported to comp.lang.python ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 08:21 Message: Logged In: YES user_id=6380 Fixed in 2.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=585882&group_id=5470 From noreply@sourceforge.net Mon Oct 14 13:48:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 05:48:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-622831 ] textwrap fails on unicode using defaults Message-ID: Bugs item #622831, was opened at 2002-10-14 06:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622831&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) >Assigned to: Greg Ward (gward) Summary: textwrap fails on unicode using defaults Initial Comment: I don't know if this is a module bug or a documentation bug. I'm using the documentation from the manual on python.org. >>> x = TextWrapper() >>> x.wrap(u'abcd') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/textwrap.py", line 239, in wrap text = self._munge_whitespace(text) File "/usr/local/lib/python2.3/textwrap.py", line 99, in _munge_whitespace text = text.translate(self.whitespace_trans) TypeError: character mapping must return integer, None or unicode If you do x.replace_whitespace = True, then it will wrap the text. So either whitespace replacement needs to be fixed, or the docs need to be updated to note that you have to set replace_whitespace to false if you want to wrap unicode. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 14:48 Message: Logged In: YES user_id=21627 Greg, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622831&group_id=5470 From noreply@sourceforge.net Mon Oct 14 13:49:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 05:49:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-622849 ] inconsistent results of leading whitespace in textwrap input Message-ID: Bugs item #622849, was opened at 2002-10-14 07:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) >Assigned to: Greg Ward (gward) Summary: inconsistent results of leading whitespace in textwrap input Initial Comment: >>> x = TextWrapper() >>> x.wrap('This is a sentence that will not wrap') ['This is a sentence that will not wrap'] >>> x.wrap(' This is a sentence that will not wrap') [' This is a sentence that will not wrap'] >>> x.wrap('This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] >>> x.wrap(' This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] To me, this looks like a bug. It violates POLA, anyway (took me a while to figure out why one paragraph and only one paragraph in my output was indented more than the rest). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 From noreply@sourceforge.net Mon Oct 14 14:00:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 06:00:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-621523 ] sizeof(struct stat) changes Message-ID: Bugs item #621523, was opened at 2002-10-10 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: sizeof(struct stat) changes Initial Comment: Including Python.h changes sizeof(struct stat): ralf@gandalf:~$ cat t.c #ifdef USE_PYTHON #include #endif #include main() { printf ("sizeof=%d\n", sizeof(struct stat)); } ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2 -DUSE_PYTHON && ./a.out sizeof=96 ralf@gandalf:~$ gcc t.c && ./a.out sizeof=88 ralf@gandalf:~$ uname -a Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002 i686 unknown rechecked with gcc-3.2 and current HEAD. Platform tests is Debian woody and Debian unstable. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2002-10-14 13:00 Message: Logged In: YES user_id=17929 I read "Extending and Embedding the Python Interpreter". In 1.1 there would have been a hint: "Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included. " Funny thing here is that if I would have included before Python.h, I suppose my module would have just worked... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 11:21 Message: Logged In: YES user_id=21627 Adding documentation is certainly possible, however: At what places did you look for documentation before writing your module? Changing the Python configuration process is not possible: Python.h depends on various system headers. When those headers get included, we *must* have the LFS support enabled, because it is not possible to include the system headers a second time later. Not including system headers is also not possible, since Python.h provides API that relies on system headers, e.g. functions taking FILE*. I think this is really something for the C library to solve, which should arrange for linker warnings if you try to combine LFS objects with non-LFS objects. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2002-10-11 11:02 Message: Logged In: YES user_id=17929 Well, at least it was a problem for me. I built a shared C++ library, where one of the classes had a private member of type struct stat and a virtual destructor, and had some subclasses of this class. Then I built a python module, linking against that library. When deleting those subclasses I got segfaults and it did take me pretty long to find out why this was happening (assuming at first that I had buffer over/underruns, then suspecting the compiler...). I essentially removed all of the code from the library and it was still segfaulting. I was really surprised when I changed that struct stat to a character array of same size... The problem here is within linux, if I would compile a standalone C++ program with largefile support, linking against that library, I would get the same results. But then at least I would have known, that I didn't use standard options to compile it. A solution for this problem would be to add a warning to python's documentation, or maybe move some of those defines from pyconfig.h to a private header file (assuming here that none of the structs declared in Python.h depend on struct stat. If they did, including sys/stat.h before Python.h might also be a bad idea). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 22:22 Message: Logged In: YES user_id=33168 The problem is that Python is built with large file support. I'm running RedHat and your example works the same for me. It appears that _LARGEFILE64_SOURCE (_LARGEFILE_SOURCE on my system) is defined in pyconfig.h. So __USE_FILE_OFFSET64 gets defined in /usr/include/features.h. Python can be built without large file support, in which case the size will not change. Is this really a problem? Can it be solved by removing large file support from python? Can you include before including Python.h to solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 From noreply@sourceforge.net Mon Oct 14 14:15:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 06:15:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 10:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- >Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-14 09:15 Message: Logged In: YES user_id=271417 > Date: 2002-10-13 09:02 > Sender: jepler > Logged In: YES > user_id=2772 > > Don't shared modules need the extension .pyd instead of .dll? > No, I am able to load the .dll from the command line version of Python. Also: >>> imp.get_suffixes() [('.pyd', 'rb', 3), ('.dll', 'rb', 3), ('.py', 'r', 1), ('.pyw', 'r', 1), ('.pyc', 'rb', 2)] shows that Python is searching for DLLs. > Is sys.path[0] some absolute directory (the one containing > idle.py, for instance) instead of '.'? > Ahh, that is the true problem. sys.path in Idle is: >>> sys.path ['C:\PROGRA~1\Python22\Tools\idle', 'C:\PROGRA~1\Python22', 'C:\Program Files\Python22\DLLs', 'C:\Program Files\Python22\lib', 'C:\Program Files\Python22\lib\lib-tk', 'C:\Program Files\Python22', 'C:\Program Files \Python22\lib\site-packages'] while sys.path in the command line interpreter is: >>> sys.path ['', 'C:\PROGRA~1\Python22', 'C:\Program Files\Python22\DLLs', 'C:\Program Files\Python22\lib', 'C:\Program Files\Python22\lib\lib-tk', 'C:\Program Files\Python22', 'C:\Program Files\Python22\lib\site-packages'] So the correct title for this bug report should be "Idle replaces sys.path[0] rather than appending a new entry to the list". This means that programs that work when run through the command-line interpreter may break quite dramatically when run from Idle, and vice versa. Leslie ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-10-13 09:02 Message: Logged In: YES user_id=2772 Don't shared modules need the extension .pyd instead of .dll? Is sys.path[0] some absolute directory (the one containing idle.py, for instance) instead of '.'? Is there a way to run idle with -v so that it lists directories and files it tries to import as modules? ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-07 17:53 Message: Logged In: YES user_id=271417 I should have noted that 'import' _does_ work to a degree - 'import os' worked. The '_example.dll' that I am trying to import is the 'shapes' example that is distributed with SWIG 1.3.15, and should import without any trouble. It does import just fine from the command line version of Python, but not from Idle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 From noreply@sourceforge.net Mon Oct 14 14:23:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 06:23:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-621523 ] sizeof(struct stat) changes Message-ID: Bugs item #621523, was opened at 2002-10-10 21:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. Löwis (loewis) Summary: sizeof(struct stat) changes Initial Comment: Including Python.h changes sizeof(struct stat): ralf@gandalf:~$ cat t.c #ifdef USE_PYTHON #include #endif #include main() { printf ("sizeof=%d\n", sizeof(struct stat)); } ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2 -DUSE_PYTHON && ./a.out sizeof=96 ralf@gandalf:~$ gcc t.c && ./a.out sizeof=88 ralf@gandalf:~$ uname -a Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002 i686 unknown rechecked with gcc-3.2 and current HEAD. Platform tests is Debian woody and Debian unstable. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2002-10-14 15:00 Message: Logged In: YES user_id=17929 I read "Extending and Embedding the Python Interpreter". In 1.1 there would have been a hint: "Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included. " Funny thing here is that if I would have included before Python.h, I suppose my module would have just worked... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 13:21 Message: Logged In: YES user_id=21627 Adding documentation is certainly possible, however: At what places did you look for documentation before writing your module? Changing the Python configuration process is not possible: Python.h depends on various system headers. When those headers get included, we *must* have the LFS support enabled, because it is not possible to include the system headers a second time later. Not including system headers is also not possible, since Python.h provides API that relies on system headers, e.g. functions taking FILE*. I think this is really something for the C library to solve, which should arrange for linker warnings if you try to combine LFS objects with non-LFS objects. ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2002-10-11 13:02 Message: Logged In: YES user_id=17929 Well, at least it was a problem for me. I built a shared C++ library, where one of the classes had a private member of type struct stat and a virtual destructor, and had some subclasses of this class. Then I built a python module, linking against that library. When deleting those subclasses I got segfaults and it did take me pretty long to find out why this was happening (assuming at first that I had buffer over/underruns, then suspecting the compiler...). I essentially removed all of the code from the library and it was still segfaulting. I was really surprised when I changed that struct stat to a character array of same size... The problem here is within linux, if I would compile a standalone C++ program with largefile support, linking against that library, I would get the same results. But then at least I would have known, that I didn't use standard options to compile it. A solution for this problem would be to add a warning to python's documentation, or maybe move some of those defines from pyconfig.h to a private header file (assuming here that none of the structs declared in Python.h depend on struct stat. If they did, including sys/stat.h before Python.h might also be a bad idea). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 00:22 Message: Logged In: YES user_id=33168 The problem is that Python is built with large file support. I'm running RedHat and your example works the same for me. It appears that _LARGEFILE64_SOURCE (_LARGEFILE_SOURCE on my system) is defined in pyconfig.h. So __USE_FILE_OFFSET64 gets defined in /usr/include/features.h. Python can be built without large file support, in which case the size will not change. Is this really a problem? Can it be solved by removing large file support from python? Can you include before including Python.h to solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621523&group_id=5470 From noreply@sourceforge.net Mon Oct 14 17:08:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 09:08:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-581165 ] smtplib.SMTP.ehlo method esmtp_features Message-ID: Bugs item #581165, was opened at 2002-07-14 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.ehlo method esmtp_features Initial Comment: The ehlo() method in the smtplib class SMTP appears to incorrectly handle the response from Eudora Internet Mail Server 3.1.3 . The rsponse to the "EHLO" command is: send: 'ehlo gemini.cs.usyd.edu.au\r\n' reply: '250-webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)\r\n' reply: '250-EXPN\r\n' reply: '250-PIPELINING\r\n' reply: '250-8BITMIME\r\n' reply: '250-BINARYMIME\r\n' reply: '250-CHUNKING\r\n' reply: '250-ENHANCEDSTATUSCODES\r\n' reply: '250-ETRN\r\n' reply: '250-AUTH CRAM-MD5 NTLM PLAIN LOGIN\r\n' reply: '250-AUTH=LOGIN\r\n' reply: '250 SIZE 2147483647\r\n' which is then gathered into: ['webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME', 'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE 2147483647'] which is then parsed into "self.esmtp_features as: {'enhancedstatuscodes': '', '8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '', 'pipelining': '', 'size': '2147483647', 'auth': '=LOGIN', 'binarymime': ''} Note that the two lines starting "AUTH" have been elided into the one dictionary element 'auth':'=LOGIN'. This prevents a subsequent call to the login() method from correctly identifying a suitable authentication method resulting in: raise SMTPException("No suitable authentication method found.") ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-14 18:08 Message: Logged In: YES user_id=163326 Maybe we should add an additional optional argument to the login() method? Something like: def login(user, password, method=smtplib.AUTH_CRAM_MD5) ? ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-08-07 07:01 Message: Logged In: YES user_id=196212 I tried the second patch. It got the same problem with "AUTH CRAM-MD5" ("Syntax Error, not using as end of line.") but then I tried forcing "AUTH LOGIN" (which I think is what your change applied to?) and that worked. Thanks! So, I think the problem is a bug on this particular smtp server, and I'm now happy because I can send mail to it using AUTH LOGIN (and the AUTH=LOGIN feature no longer causes a problem for smtplib.py) The question is - should CRAM-MD5 be the preferred method? I think the answer is yes as it is more secure, but perhaps a note could be installed somewhere to use LOGIN authentication if the error occurs. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 08:56 Message: Logged In: YES user_id=163326 Piers, could you please try my patch again? It contained a very stupid bug (sent the username twice, but no password). This seems unrelated to the error message your SMTP server sent, but maybe it's worth a try. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-07-24 13:26 Message: Logged In: YES user_id=196212 I tried the patch. It gets me further - I now get "Syntax Error, not using as end of line." Here's the trace: resp: ['webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME', 'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE 2147483647'] features: {'auth=login': '', 'enhancedstatuscodes': '', '8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '', 'pipelining': '', 'size': '2147483647', 'auth': 'CRAM-MD5 NTLM PLAIN LOGIN', 'binarymime': ''} send: 'AUTH CRAM-MD5\r\n' reply: '334 PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+\r\n' reply: retcode (334); Msg: PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+ send: 'cGllcnMlY29tbXVuaXR5c29sdXRpb25zLmNvbS5hdSAzOTU2NzVmYWUwZGUxZmQyN2I3MTRjNGQ5\nYzgzOWIwNQ==\r\n' reply: '500 Syntax error, not using as end of line\r\n' reply: retcode (500); Msg: Syntax error, not using as end of line Which doesn't make any sense, and is probably a server problem, since I can see that each line sent _is_ terminated with . So I consider the patch a (qualified) success. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 00:00 Message: Logged In: YES user_id=21627 Can you please try the patch in http://sourceforge.net/tracker/index.php? func=detail&aid=572031&group_id=5470&atid=305470 and report whether it solves this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 From noreply@sourceforge.net Mon Oct 14 17:04:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 09:04:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-611052 ] SMTP.login() uses invalid base64 enc. Message-ID: Bugs item #611052, was opened at 2002-09-18 13:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=611052&group_id=5470 Category: Extension Modules Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Ondrej Sury (ondrass) Assigned to: Nobody/Anonymous (nobody) Summary: SMTP.login() uses invalid base64 enc. Initial Comment: If you have veeery long username and/or password it encodes it with '\n' after 80? characters. This violates (IMHO) smtp standard. In following example look for \n characters. O. >>> from smtplib import SMTP >>> s = SMTP('smtp.servery.cz') >>> s.set_debuglevel(255) >>> s.login('veeeery.looooong.username@veeeeery.loooooong.domain', 'veeeeery.loooong.password') send: 'ehlo shade.globe.cz\r\n' reply: '250-smtp.cz\r\n' reply: '250-AUTH LOGIN PLAIN\r\n' reply: '250-AUTH=LOGIN PLAIN\r\n' reply: '250-PIPELINING\r\n' reply: '250-STARTTLS\r\n' reply: '250 8BITMIME\r\n' reply: retcode (250); Msg: smtp.cz AUTH LOGIN PLAIN AUTH=LOGIN PLAIN PIPELINING STARTTLS 8BITMIME AuthMethod: PLAIN send: 'AUTH PLAIN dmVlZWVyeS5sb29vb29uZy51c2VybmFtZUB2ZWVlZWVyeS5sb29vb29vbmcuZG9tYWluAHZlZWVl\ncnkubG9vb29vbmcudXNlcm5hbWVAdmVlZWVlcnkubG9vb29vb25nLmRvbWFpbgB2ZWVlZWVyeS5s\nb29vb25nLnBhc3N3b3Jk\r\n' reply: '501 malformed auth input (#5.5.4)\r\n' reply: retcode (501); Msg: malformed auth input (#5.5.4) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/smtplib.py", line 546, in login raise SMTPAuthenticationError(code, resp) smtplib.SMTPAuthenticationError: (501, 'malformed auth input (#5.5.4)') ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-14 18:04 Message: Logged In: YES user_id=163326 Thanks for the bug report. This has already been fixed in Python 2.3-CVS and the 2.2 maintenance branch. So just upgrade to Python 2.2.2 when it'll be out tomorrow :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=611052&group_id=5470 From noreply@sourceforge.net Mon Oct 14 19:37:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 11:37:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-581165 ] smtplib.SMTP.ehlo method esmtp_features Message-ID: Bugs item #581165, was opened at 2002-07-14 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.ehlo method esmtp_features Initial Comment: The ehlo() method in the smtplib class SMTP appears to incorrectly handle the response from Eudora Internet Mail Server 3.1.3 . The rsponse to the "EHLO" command is: send: 'ehlo gemini.cs.usyd.edu.au\r\n' reply: '250-webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)\r\n' reply: '250-EXPN\r\n' reply: '250-PIPELINING\r\n' reply: '250-8BITMIME\r\n' reply: '250-BINARYMIME\r\n' reply: '250-CHUNKING\r\n' reply: '250-ENHANCEDSTATUSCODES\r\n' reply: '250-ETRN\r\n' reply: '250-AUTH CRAM-MD5 NTLM PLAIN LOGIN\r\n' reply: '250-AUTH=LOGIN\r\n' reply: '250 SIZE 2147483647\r\n' which is then gathered into: ['webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME', 'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE 2147483647'] which is then parsed into "self.esmtp_features as: {'enhancedstatuscodes': '', '8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '', 'pipelining': '', 'size': '2147483647', 'auth': '=LOGIN', 'binarymime': ''} Note that the two lines starting "AUTH" have been elided into the one dictionary element 'auth':'=LOGIN'. This prevents a subsequent call to the login() method from correctly identifying a suitable authentication method resulting in: raise SMTPException("No suitable authentication method found.") ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 20:37 Message: Logged In: YES user_id=21627 I got the impression that the original problem reported has been fixed. Is that impression incorrect? If this is fixed, we should close this report. As for adding new parameters: I'd like to get a real-world bug report first, which then should be tracked separately. As for using CRAM-MD5: Correct me if I'm wrong, but doesn't that require clear text passwords on the server, and thus cannot be implemented on top of a /etc/passwd database? If so, I wonder whether it is used in real life. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-14 18:08 Message: Logged In: YES user_id=163326 Maybe we should add an additional optional argument to the login() method? Something like: def login(user, password, method=smtplib.AUTH_CRAM_MD5) ? ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-08-07 07:01 Message: Logged In: YES user_id=196212 I tried the second patch. It got the same problem with "AUTH CRAM-MD5" ("Syntax Error, not using as end of line.") but then I tried forcing "AUTH LOGIN" (which I think is what your change applied to?) and that worked. Thanks! So, I think the problem is a bug on this particular smtp server, and I'm now happy because I can send mail to it using AUTH LOGIN (and the AUTH=LOGIN feature no longer causes a problem for smtplib.py) The question is - should CRAM-MD5 be the preferred method? I think the answer is yes as it is more secure, but perhaps a note could be installed somewhere to use LOGIN authentication if the error occurs. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 08:56 Message: Logged In: YES user_id=163326 Piers, could you please try my patch again? It contained a very stupid bug (sent the username twice, but no password). This seems unrelated to the error message your SMTP server sent, but maybe it's worth a try. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-07-24 13:26 Message: Logged In: YES user_id=196212 I tried the patch. It gets me further - I now get "Syntax Error, not using as end of line." Here's the trace: resp: ['webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME', 'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE 2147483647'] features: {'auth=login': '', 'enhancedstatuscodes': '', '8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '', 'pipelining': '', 'size': '2147483647', 'auth': 'CRAM-MD5 NTLM PLAIN LOGIN', 'binarymime': ''} send: 'AUTH CRAM-MD5\r\n' reply: '334 PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+\r\n' reply: retcode (334); Msg: PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+ send: 'cGllcnMlY29tbXVuaXR5c29sdXRpb25zLmNvbS5hdSAzOTU2NzVmYWUwZGUxZmQyN2I3MTRjNGQ5\nYzgzOWIwNQ==\r\n' reply: '500 Syntax error, not using as end of line\r\n' reply: retcode (500); Msg: Syntax error, not using as end of line Which doesn't make any sense, and is probably a server problem, since I can see that each line sent _is_ terminated with . So I consider the patch a (qualified) success. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 00:00 Message: Logged In: YES user_id=21627 Can you please try the patch in http://sourceforge.net/tracker/index.php? func=detail&aid=572031&group_id=5470&atid=305470 and report whether it solves this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 From noreply@sourceforge.net Mon Oct 14 19:54:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 11:54:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-581165 ] smtplib.SMTP.ehlo method esmtp_features Message-ID: Bugs item #581165, was opened at 2002-07-14 01:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.ehlo method esmtp_features Initial Comment: The ehlo() method in the smtplib class SMTP appears to incorrectly handle the response from Eudora Internet Mail Server 3.1.3 . The rsponse to the "EHLO" command is: send: 'ehlo gemini.cs.usyd.edu.au\r\n' reply: '250-webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)\r\n' reply: '250-EXPN\r\n' reply: '250-PIPELINING\r\n' reply: '250-8BITMIME\r\n' reply: '250-BINARYMIME\r\n' reply: '250-CHUNKING\r\n' reply: '250-ENHANCEDSTATUSCODES\r\n' reply: '250-ETRN\r\n' reply: '250-AUTH CRAM-MD5 NTLM PLAIN LOGIN\r\n' reply: '250-AUTH=LOGIN\r\n' reply: '250 SIZE 2147483647\r\n' which is then gathered into: ['webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME', 'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE 2147483647'] which is then parsed into "self.esmtp_features as: {'enhancedstatuscodes': '', '8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '', 'pipelining': '', 'size': '2147483647', 'auth': '=LOGIN', 'binarymime': ''} Note that the two lines starting "AUTH" have been elided into the one dictionary element 'auth':'=LOGIN'. This prevents a subsequent call to the login() method from correctly identifying a suitable authentication method resulting in: raise SMTPException("No suitable authentication method found.") ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-14 20:54 Message: Logged In: YES user_id=163326 Yes, the original problem was that we didn't parse AUTH= lines and this has been fixed. Apparently the reason the current code doesn't work for Piers is that his SMTP server has problems with CRAM-MD5 although it says that it'll understand CRAM-MD5. I can think of two workarounds: - the additional argument like I proposedlibrary - smtp.login() tries the advertised auth methods until it finds one that works. But I don't like such hacks, as they make debugging problems even more difficult. If anybody actually wants one of these, they should perhaps file a feature request or a patch, so this one can be closed. On your other question, I don't have access to a "real-life" SMTP AUTH server except MS Exchange (of which we only support LOGIN). You're right about not being able to use /etc/passwd, but I believe most Unix MTAs support virtual users, so this should not be a problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 20:37 Message: Logged In: YES user_id=21627 I got the impression that the original problem reported has been fixed. Is that impression incorrect? If this is fixed, we should close this report. As for adding new parameters: I'd like to get a real-world bug report first, which then should be tracked separately. As for using CRAM-MD5: Correct me if I'm wrong, but doesn't that require clear text passwords on the server, and thus cannot be implemented on top of a /etc/passwd database? If so, I wonder whether it is used in real life. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-14 18:08 Message: Logged In: YES user_id=163326 Maybe we should add an additional optional argument to the login() method? Something like: def login(user, password, method=smtplib.AUTH_CRAM_MD5) ? ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-08-07 07:01 Message: Logged In: YES user_id=196212 I tried the second patch. It got the same problem with "AUTH CRAM-MD5" ("Syntax Error, not using as end of line.") but then I tried forcing "AUTH LOGIN" (which I think is what your change applied to?) and that worked. Thanks! So, I think the problem is a bug on this particular smtp server, and I'm now happy because I can send mail to it using AUTH LOGIN (and the AUTH=LOGIN feature no longer causes a problem for smtplib.py) The question is - should CRAM-MD5 be the preferred method? I think the answer is yes as it is more secure, but perhaps a note could be installed somewhere to use LOGIN authentication if the error occurs. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 08:56 Message: Logged In: YES user_id=163326 Piers, could you please try my patch again? It contained a very stupid bug (sent the username twice, but no password). This seems unrelated to the error message your SMTP server sent, but maybe it's worth a try. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-07-24 13:26 Message: Logged In: YES user_id=196212 I tried the patch. It gets me further - I now get "Syntax Error, not using as end of line." Here's the trace: resp: ['webfactory.com.au hello gemini.cs.usyd.edu.au (129.78.111.139)', 'EXPN', 'PIPELINING', '8BITMIME', 'BINARYMIME', 'CHUNKING', 'ENHANCEDSTATUSCODES', 'ETRN', 'AUTH CRAM-MD5 NTLM PLAIN LOGIN', 'AUTH=LOGIN', 'SIZE 2147483647'] features: {'auth=login': '', 'enhancedstatuscodes': '', '8bitmime': '', 'expn': '', 'chunking': '', 'etrn': '', 'pipelining': '', 'size': '2147483647', 'auth': 'CRAM-MD5 NTLM PLAIN LOGIN', 'binarymime': ''} send: 'AUTH CRAM-MD5\r\n' reply: '334 PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+\r\n' reply: retcode (334); Msg: PDExODQ1NzY3NTctNjk3MjgzMDhAd2ViZmFjdG9yeS5jb20uYXU+ send: 'cGllcnMlY29tbXVuaXR5c29sdXRpb25zLmNvbS5hdSAzOTU2NzVmYWUwZGUxZmQyN2I3MTRjNGQ5\nYzgzOWIwNQ==\r\n' reply: '500 Syntax error, not using as end of line\r\n' reply: retcode (500); Msg: Syntax error, not using as end of line Which doesn't make any sense, and is probably a server problem, since I can see that each line sent _is_ terminated with . So I consider the patch a (qualified) success. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 00:00 Message: Logged In: YES user_id=21627 Can you please try the patch in http://sourceforge.net/tracker/index.php? func=detail&aid=572031&group_id=5470&atid=305470 and report whether it solves this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 From noreply@sourceforge.net Mon Oct 14 20:24:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 12:24:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-620705 ] websucker relative-URL errors Message-ID: Bugs item #620705, was opened at 2002-10-09 06:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 Category: Demos and Tools >Group: Python 2.3 Status: Open Resolution: None >Priority: 9 Submitted By: Alex Martelli (aleax) >Assigned to: Guido van Rossum (gvanrossum) Summary: websucker relative-URL errors Initial Comment: reproduce easily with, e.g.: python websucker.py -v http://www.aleax.it gives a series of error messages such as: Check http://www.aleax.it/./py2.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/./py2.htm from http://www.aleax.it/./Python/ (///./py2.htm) Check http://www.aleax.it/p1.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/p1.htm from http://www.aleax.it/./TutWin32/index.htm (///p1.htm) but the relevant snippets of the HTML sources are e.g: in Python/index.html: in TutWin32/index.html: i.e. both relative URLs, so should resolve to the URLs of the files that ARE present, Python/py2.htm and TutWin32/p1.htm respectively. And indeed /usr/bin/wget has no problem fetching the whole small site. Pls let me know if you want me to explore the bug further and prepare a patch in time for 2.2.2 release -- otherwise I think this shd at least be documented as a known bug (making websucker close to unusable, alas). Alex ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 15:24 Message: Logged In: YES user_id=6380 Argh! This looks like a bug in urlparse.py, introduced somewhere in or after 2.2. In 2.1, or in 2.2.1: >>> import urlparse >>> urlparse.urlunparse(urlparse.urlparse('./Python')) './Python' >>> In 2.2.2 or 2.3: >>> import urlparse >>> urlparse.urlunparse(urlparse.urlparse('./Python')) '///./Python' >>> I' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 From noreply@sourceforge.net Mon Oct 14 20:39:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 12:39:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-621526 ] docs do not include spec info from PEPs Message-ID: Bugs item #621526, was opened at 2002-10-10 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs do not include spec info from PEPs Initial Comment: [please see http://bugs.debian.org/163703] The bug submitter complains, that the information found in accepted PEPs like 252 and 253 cannot be found in the "standard documentation" and proposes, that accepted PEPs are included in the standard documentation. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-10-14 19:39 Message: Logged In: YES user_id=31392 Well it's not a question of cutting and pasting the spec part of a PEP into the reference manual. The documentation changes, particularly for PEPs 252 and 253, are fairly substantial and involve a lot more than moving some text around. (I'd wager that what counts as standard features and what is experimental isn't entirely clear.) To sum up, I don't think there's much point keeping a bug report open for this unless there are a specific set of PEPs with tractable documentation to move around. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-12 07:53 Message: Logged In: YES user_id=60903 Ok, changed the summary line. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 14:48 Message: Logged In: YES user_id=31392 I don't think PEPs themselves should be included in the documentation, but the relevant spec info should go into the docs in an appropriate location. I think leaving the rationale/discussion part in the PEP is good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 From noreply@sourceforge.net Mon Oct 14 20:40:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 12:40:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-620705 ] websucker relative-URL errors Message-ID: Bugs item #620705, was opened at 2002-10-09 06:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 Category: Demos and Tools >Group: Python 2.2.2 Status: Open Resolution: None Priority: 9 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: websucker relative-URL errors Initial Comment: reproduce easily with, e.g.: python websucker.py -v http://www.aleax.it gives a series of error messages such as: Check http://www.aleax.it/./py2.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/./py2.htm from http://www.aleax.it/./Python/ (///./py2.htm) Check http://www.aleax.it/p1.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/p1.htm from http://www.aleax.it/./TutWin32/index.htm (///p1.htm) but the relevant snippets of the HTML sources are e.g: in Python/index.html: in TutWin32/index.html: i.e. both relative URLs, so should resolve to the URLs of the files that ARE present, Python/py2.htm and TutWin32/p1.htm respectively. And indeed /usr/bin/wget has no problem fetching the whole small site. Pls let me know if you want me to explore the bug further and prepare a patch in time for 2.2.2 release -- otherwise I think this shd at least be documented as a known bug (making websucker close to unusable, alas). Alex ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 15:24 Message: Logged In: YES user_id=6380 Argh! This looks like a bug in urlparse.py, introduced somewhere in or after 2.2. In 2.1, or in 2.2.1: >>> import urlparse >>> urlparse.urlunparse(urlparse.urlparse('./Python')) './Python' >>> In 2.2.2 or 2.3: >>> import urlparse >>> urlparse.urlunparse(urlparse.urlparse('./Python')) '///./Python' >>> I' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 From noreply@sourceforge.net Mon Oct 14 20:55:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 12:55:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-621526 ] docs do not include spec info from PEPs Message-ID: Bugs item #621526, was opened at 2002-10-10 15:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs do not include spec info from PEPs Initial Comment: [please see http://bugs.debian.org/163703] The bug submitter complains, that the information found in accepted PEPs like 252 and 253 cannot be found in the "standard documentation" and proposes, that accepted PEPs are included in the standard documentation. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-14 15:55 Message: Logged In: YES user_id=3066 I agree with Jeremy. If something is described in a PEP and implemented, documentation is necessary. For each such case, a separate documentation bug should be filed. This is especially valuable since I don't have time to follow PEP development these days. Specific bug reports would be very helpful, and can get things moving a little quicker. Such a report should include: - what isn't documented - where you think documentation should be added (possibly multiple locations) - what the documentation should say (a reference to a PEP, email message, or a patch would all be good), if possible. I'm closing this report and anxiously awaiting a deluge of very specific and helpful reports. Thanks, Volunteer Matthias! ;-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-14 15:39 Message: Logged In: YES user_id=31392 Well it's not a question of cutting and pasting the spec part of a PEP into the reference manual. The documentation changes, particularly for PEPs 252 and 253, are fairly substantial and involve a lot more than moving some text around. (I'd wager that what counts as standard features and what is experimental isn't entirely clear.) To sum up, I don't think there's much point keeping a bug report open for this unless there are a specific set of PEPs with tractable documentation to move around. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-12 03:53 Message: Logged In: YES user_id=60903 Ok, changed the summary line. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 10:48 Message: Logged In: YES user_id=31392 I don't think PEPs themselves should be included in the documentation, but the relevant spec info should go into the docs in an appropriate location. I think leaving the rationale/discussion part in the PEP is good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621526&group_id=5470 From noreply@sourceforge.net Mon Oct 14 21:07:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 13:07:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-623196 ] urllib.pathname2url(), .url2pathname() Message-ID: Bugs item #623196, was opened at 2002-10-14 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623196&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: urllib.pathname2url(), .url2pathname() Initial Comment: These two functions are not documented, nor do they have docstrings. This should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623196&group_id=5470 From noreply@sourceforge.net Mon Oct 14 21:09:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 13:09:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-620705 ] websucker relative-URL errors Message-ID: Bugs item #620705, was opened at 2002-10-09 06:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 >Status: Closed Resolution: None Priority: 9 Submitted By: Alex Martelli (aleax) Assigned to: Guido van Rossum (gvanrossum) Summary: websucker relative-URL errors Initial Comment: reproduce easily with, e.g.: python websucker.py -v http://www.aleax.it gives a series of error messages such as: Check http://www.aleax.it/./py2.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/./py2.htm from http://www.aleax.it/./Python/ (///./py2.htm) Check http://www.aleax.it/p1.htm Error ('http error', 404, 'Object Not Found') HREF http://www.aleax.it/p1.htm from http://www.aleax.it/./TutWin32/index.htm (///p1.htm) but the relevant snippets of the HTML sources are e.g: in Python/index.html: in TutWin32/index.html: i.e. both relative URLs, so should resolve to the URLs of the files that ARE present, Python/py2.htm and TutWin32/p1.htm respectively. And indeed /usr/bin/wget has no problem fetching the whole small site. Pls let me know if you want me to explore the bug further and prepare a patch in time for 2.2.2 release -- otherwise I think this shd at least be documented as a known bug (making websucker close to unusable, alas). Alex ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 16:09 Message: Logged In: YES user_id=6380 OK, fixed in 2.2.2 and 2.3. Whew! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 15:24 Message: Logged In: YES user_id=6380 Argh! This looks like a bug in urlparse.py, introduced somewhere in or after 2.2. In 2.1, or in 2.2.1: >>> import urlparse >>> urlparse.urlunparse(urlparse.urlparse('./Python')) './Python' >>> In 2.2.2 or 2.3: >>> import urlparse >>> urlparse.urlunparse(urlparse.urlparse('./Python')) '///./Python' >>> I' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620705&group_id=5470 From noreply@sourceforge.net Mon Oct 14 21:40:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 13:40:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-620364 ] core setup.py fails on Windows Message-ID: Bugs item #620364, was opened at 2002-10-08 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 Category: Build Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: core setup.py fails on Windows Initial Comment: 1. Extract Python-2.2.2b1.tgz into a directory (E:\dev\python\src in this case). 2. Run 'python setup.py build' in the source root directory. 3. Witness the bug (output shown at the bottom of this message). The problem is that on line 81 of setup.py, the srcdir is set to None rather than a meaningful directory name (distutils.sysconfig.get_config_vars('srcdir') returns [None]). The traceback below arises on line 84, when None is passed as an argument to os.path.join. My operating system is Windows 2000, and I have MSVC 6 installed. The compiler is configured properly; I've built many other distutils-ified extensions without a hitch. This bug arises regardless of whether the Python-2.2.1 version of distutils or the Python-2.2.2b1 version of distutils is used (both versions are labeled as distutils 1.0.3). To generate the traceback shown below, I used the official Windows binary distribution of Python-2.2.1 (that is, the 'python' in 'python setup.py build' referred to Python-2.2.1), but the results are the same if I compile Python-2.2.2b1 by other means and then attempt to use the resulting executable to run its own distutils setup script. ---------------------------------------------------------- E:\dev\python\src\Python-2.2.2b1>python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 792, in ? main() File "setup.py", line 787, in main scripts = ['Tools/scripts/pydoc'] File "e:\dev\python\core\lib\distutils\core.py", line 138, in setup dist.run_commands() File "e:\dev\python\core\lib\distutils\dist.py", line 893, in run_commands self.run_command(cmd) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build.py", line 107, in run self.run_command(cmd_name) File "e:\dev\python\core\lib\distutils\cmd.py", line 330, in run_command self.distribution.run_command(command) File "e:\dev\python\core\lib\distutils\dist.py", line 913, in run_command cmd_obj.run() File "e:\dev\python\core\lib\distutils\command\build_ext.py", line 256, in run self.build_extensions() File "setup.py", line 84, in build_extensions moddir = os.path.join(os.getcwd(), srcdir, 'Modules') File "E:\dev\python\core\Lib\ntpath.py", line 49, in join elif isabs(b): File "E:\dev\python\core\Lib\ntpath.py", line 35, in isabs s = splitdrive(s)[1] File "E:\dev\python\core\Lib\ntpath.py", line 101, in splitdrive if p[1:2] == ':': TypeError: unsubscriptable object ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 16:40 Message: Logged In: YES user_id=6380 I'll fix this in 2.3. ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2002-10-13 16:04 Message: Logged In: YES user_id=414645 Done: http://sourceforge.net/tracker/index.php? func=detail&aid=622704&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-13 10:56 Message: Logged In: YES user_id=6380 Please submit an actual patch in context diff format. I'd be happy to fix this in 2.3 but I've lowered the priority appropriately. ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2002-10-09 08:23 Message: Logged In: YES user_id=414645 > This is by design, the Python distribution itself is not build > using setup.py, except for Cygwin targets. I can accept that readily enough, but shouldn't setup.py raise a more meaningful error message, instead of gracelessly dumping a traceback that occurs when it tries to pass an erroneous value (None) to os.path.join? The current behavior may be by design, but to the uninitiated, it *very* strongly resembles a bug. Why not test srcdir (created on line 81 in the current setup.py) to see if it's a meaningful value, and raise an informative error message if not? Like this (line width ridiculously constrained for the sake of SF's forum): ################################################## (srcdir,) = sysconfig.get_config_vars('srcdir') if not srcDir: raise EnvironmentError("The system configuration" " variable 'srcdir' is not defined, so this" " setup script cannot continue. This error" " probably arose because this setup script" " is only designed to run in the Cygwin" " environment, yet you are attempting to" " run it elsewhere." ) ################################################## ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 02:27 Message: Logged In: YES user_id=21627 This is by design, the Python distribution itself is not build using setup.py, except for Cygwin targets. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620364&group_id=5470 From noreply@sourceforge.net Mon Oct 14 21:43:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 13:43:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-620783 ] SocketServer/socket allow_reuse_address Message-ID: Bugs item #620783, was opened at 2002-10-09 10:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Notz (notz) >Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer/socket allow_reuse_address Initial Comment: The SocketServer.TCPServer.server_bind() method contains the following code: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) On SunOS and Linux (possibly others) this only appears to work if the third argument is changed to "2". Perhaps this is also a bug with the lower-level socket package's setsockopt() function (I mean, perhaps it *should* work with a value of "1"). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 16:43 Message: Logged In: YES user_id=6380 Are you sure about Linux? I've used this code successfully on Linux with '1'. Can you point to documentation that prove your point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 From noreply@sourceforge.net Mon Oct 14 21:49:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 13:49:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-616019 ] list(xrange(sys.maxint / 4)) -> swapping Message-ID: Bugs item #616019, was opened at 2002-09-28 22:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint / 4)) -> swapping Initial Comment: Refer to #556025 list(xrange(1e9)) --> seg fault for the history. The test in test/test_b1.py causes OS X 10.2.1 to start swapping instantly and never stopped until I killed the process after 5 minutes. I wasn't brave enough to let it run for any longer. list(xrange(1e09)) or even list(xrange(sys.maxint)) works: Traceback (most recent call last): File "test_b1.py", line 553, in ? list(xrange(sys.maxint)) MemoryError PhysMem: 55.7M wired, 300M active, 150M inactive, 506M used, 6.19M free VM: 4.19G + 76.9M 36909(35) pageins, 1505603(200) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1157 python 9.1% 0:33.72 1 13 1186 373M+ 1.55M 160M- 2.29G+ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-14 16:49 Message: Logged In: YES user_id=33168 This problem was recently addressed by changing sys.maxint / 4 to sys.maxint / 2. Brian, do you still have the problem? ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-07 18:29 Message: Logged In: YES user_id=17671 Forget what I said in the last comment. I must have been asleep. The problem boils down to this: OS X does lazy memory allocation and each process gets up to 4GB of virtual memory. I now know a lot more about how the interpreter manages memory. I could have saved myself the trouble by paying attention to what the VM: 4.19G+ in top was telling me. The test in test_b1.py should not be run on OS X. I am going to avoid problems like this in the future by setting a hard limit on per process memory of 400MB. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-06 05:31 Message: Logged In: YES user_id=17671 I did a little more digging on this problem. I don't understand why this is happening yet, but I also think I found a bug in obmalloc.c I built a debug interpreter with PYMALLOC_DEBUG after I ran test_b1.py in gdb and saw memset being called with a bogus argument: #1 0x0009722c in _PyObject_DebugMalloc (nbytes=2147483648) at Objects/obmalloc.c:998 nbytes here should be sys.maxint / 4 + 16, but instead memset is being called with sys.maxint + 16. obmalloc.c line 981: total = nbytes + 16 if (total < nbytes || (total >> 31) > 1) { .... return NULL total is a uchar and nbytes is a size_t. Neither side of this test is true if total = sys.maxint + 16 has overflowed: total: 2147483664 nbytes: -2147483632 It seems to me the test should be: if (total < nbytes || (total >> 31) >= 1) { Changing obmalloc.c as above, fixes the swapping, but brings me no closer to finding the actual cause of the poblem. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-01 00:30 Message: Logged In: YES user_id=17671 OK, I added a fprintf to the NRESIZE macro and got the same results on three different platforms, but both OS X builds start swapping rather than raising a MemoryError. I guess the next place to look is PyMem_RESIZE Windows-XP-5.1.2600-SP1: Linux (glibc2.1.3): OS X 10.2.1 (gcc3): OS X 10.2.1 (gcc 2.95.2): sys.maxint: 2147483647 test_b1.py: list _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 536870912 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:01 Message: Logged In: YES user_id=21627 Can you please find out how much memory it tries to allocate? The easiest approach might be add a print statement; I *think* the relevant allocation should come from the NRESIZE macro - we'd need to find out what value _new_size has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 From noreply@sourceforge.net Mon Oct 14 22:12:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 14:12:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-616019 ] list(xrange(sys.maxint / 4)) -> swapping Message-ID: Bugs item #616019, was opened at 2002-09-29 02:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint / 4)) -> swapping Initial Comment: Refer to #556025 list(xrange(1e9)) --> seg fault for the history. The test in test/test_b1.py causes OS X 10.2.1 to start swapping instantly and never stopped until I killed the process after 5 minutes. I wasn't brave enough to let it run for any longer. list(xrange(1e09)) or even list(xrange(sys.maxint)) works: Traceback (most recent call last): File "test_b1.py", line 553, in ? list(xrange(sys.maxint)) MemoryError PhysMem: 55.7M wired, 300M active, 150M inactive, 506M used, 6.19M free VM: 4.19G + 76.9M 36909(35) pageins, 1505603(200) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1157 python 9.1% 0:33.72 1 13 1186 373M+ 1.55M 160M- 2.29G+ ---------------------------------------------------------------------- >Comment By: Brian Lenihan (brianl) Date: 2002-10-14 21:12 Message: Logged In: YES user_id=17671 Nope. Tim's change fixed it. I've verified that it works in 2.3 on OS X 10.2.1 and 2.2.2 on XP. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-14 20:49 Message: Logged In: YES user_id=33168 This problem was recently addressed by changing sys.maxint / 4 to sys.maxint / 2. Brian, do you still have the problem? ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-07 22:29 Message: Logged In: YES user_id=17671 Forget what I said in the last comment. I must have been asleep. The problem boils down to this: OS X does lazy memory allocation and each process gets up to 4GB of virtual memory. I now know a lot more about how the interpreter manages memory. I could have saved myself the trouble by paying attention to what the VM: 4.19G+ in top was telling me. The test in test_b1.py should not be run on OS X. I am going to avoid problems like this in the future by setting a hard limit on per process memory of 400MB. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-06 09:31 Message: Logged In: YES user_id=17671 I did a little more digging on this problem. I don't understand why this is happening yet, but I also think I found a bug in obmalloc.c I built a debug interpreter with PYMALLOC_DEBUG after I ran test_b1.py in gdb and saw memset being called with a bogus argument: #1 0x0009722c in _PyObject_DebugMalloc (nbytes=2147483648) at Objects/obmalloc.c:998 nbytes here should be sys.maxint / 4 + 16, but instead memset is being called with sys.maxint + 16. obmalloc.c line 981: total = nbytes + 16 if (total < nbytes || (total >> 31) > 1) { .... return NULL total is a uchar and nbytes is a size_t. Neither side of this test is true if total = sys.maxint + 16 has overflowed: total: 2147483664 nbytes: -2147483632 It seems to me the test should be: if (total < nbytes || (total >> 31) >= 1) { Changing obmalloc.c as above, fixes the swapping, but brings me no closer to finding the actual cause of the poblem. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-01 04:30 Message: Logged In: YES user_id=17671 OK, I added a fprintf to the NRESIZE macro and got the same results on three different platforms, but both OS X builds start swapping rather than raising a MemoryError. I guess the next place to look is PyMem_RESIZE Windows-XP-5.1.2600-SP1: Linux (glibc2.1.3): OS X 10.2.1 (gcc3): OS X 10.2.1 (gcc 2.95.2): sys.maxint: 2147483647 test_b1.py: list _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 536870912 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 16:01 Message: Logged In: YES user_id=21627 Can you please find out how much memory it tries to allocate? The easiest approach might be add a print statement; I *think* the relevant allocation should come from the NRESIZE macro - we'd need to find out what value _new_size has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 From noreply@sourceforge.net Mon Oct 14 22:39:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 14:39:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-616019 ] list(xrange(sys.maxint / 4)) -> swapping Message-ID: Bugs item #616019, was opened at 2002-09-28 22:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: list(xrange(sys.maxint / 4)) -> swapping Initial Comment: Refer to #556025 list(xrange(1e9)) --> seg fault for the history. The test in test/test_b1.py causes OS X 10.2.1 to start swapping instantly and never stopped until I killed the process after 5 minutes. I wasn't brave enough to let it run for any longer. list(xrange(1e09)) or even list(xrange(sys.maxint)) works: Traceback (most recent call last): File "test_b1.py", line 553, in ? list(xrange(sys.maxint)) MemoryError PhysMem: 55.7M wired, 300M active, 150M inactive, 506M used, 6.19M free VM: 4.19G + 76.9M 36909(35) pageins, 1505603(200) pageouts PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1157 python 9.1% 0:33.72 1 13 1186 373M+ 1.55M 160M- 2.29G+ ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-14 17:12 Message: Logged In: YES user_id=17671 Nope. Tim's change fixed it. I've verified that it works in 2.3 on OS X 10.2.1 and 2.2.2 on XP. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-14 16:49 Message: Logged In: YES user_id=33168 This problem was recently addressed by changing sys.maxint / 4 to sys.maxint / 2. Brian, do you still have the problem? ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-07 18:29 Message: Logged In: YES user_id=17671 Forget what I said in the last comment. I must have been asleep. The problem boils down to this: OS X does lazy memory allocation and each process gets up to 4GB of virtual memory. I now know a lot more about how the interpreter manages memory. I could have saved myself the trouble by paying attention to what the VM: 4.19G+ in top was telling me. The test in test_b1.py should not be run on OS X. I am going to avoid problems like this in the future by setting a hard limit on per process memory of 400MB. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-06 05:31 Message: Logged In: YES user_id=17671 I did a little more digging on this problem. I don't understand why this is happening yet, but I also think I found a bug in obmalloc.c I built a debug interpreter with PYMALLOC_DEBUG after I ran test_b1.py in gdb and saw memset being called with a bogus argument: #1 0x0009722c in _PyObject_DebugMalloc (nbytes=2147483648) at Objects/obmalloc.c:998 nbytes here should be sys.maxint / 4 + 16, but instead memset is being called with sys.maxint + 16. obmalloc.c line 981: total = nbytes + 16 if (total < nbytes || (total >> 31) > 1) { .... return NULL total is a uchar and nbytes is a size_t. Neither side of this test is true if total = sys.maxint + 16 has overflowed: total: 2147483664 nbytes: -2147483632 It seems to me the test should be: if (total < nbytes || (total >> 31) >= 1) { Changing obmalloc.c as above, fixes the swapping, but brings me no closer to finding the actual cause of the poblem. ---------------------------------------------------------------------- Comment By: Brian Lenihan (brianl) Date: 2002-10-01 00:30 Message: Logged In: YES user_id=17671 OK, I added a fprintf to the NRESIZE macro and got the same results on three different platforms, but both OS X builds start swapping rather than raising a MemoryError. I guess the next place to look is PyMem_RESIZE Windows-XP-5.1.2600-SP1: Linux (glibc2.1.3): OS X 10.2.1 (gcc3): OS X 10.2.1 (gcc 2.95.2): sys.maxint: 2147483647 test_b1.py: list _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 8 _new_size: 536870912 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:01 Message: Logged In: YES user_id=21627 Can you please find out how much memory it tries to allocate? The easiest approach might be add a print statement; I *think* the relevant allocation should come from the NRESIZE macro - we'd need to find out what value _new_size has. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616019&group_id=5470 From noreply@sourceforge.net Tue Oct 15 00:05:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 16:05:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-621457 ] email: ASCII decoding error on 8bit data Message-ID: Bugs item #621457, was opened at 2002-10-10 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: ASCII decoding error on 8bit data Initial Comment: email 2.4.1 raises a UnicodeError when encountering 8-bit strings in rfc2822 message headers. Although this is not RFC compliant, it is commonly the case for spam messages originating from Asia. It was suggested on mimelib-devel that email should offer 'strict', 'ignore', and 'replace' modes for the programmer to decide what they want to do with invalid 8-bit data. This bug was discussed on the mimelib-devel list. See the thread starting at: http://article.gmane.org/gmane.comp.python.mime.devel/199 ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-10-14 17:05 Message: Logged In: YES user_id=85984 Upgrading to email 2.4.3 solved this problem. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 From noreply@sourceforge.net Tue Oct 15 00:47:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 16:47:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-621457 ] email: ASCII decoding error on 8bit data Message-ID: Bugs item #621457, was opened at 2002-10-10 13:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: ASCII decoding error on 8bit data Initial Comment: email 2.4.1 raises a UnicodeError when encountering 8-bit strings in rfc2822 message headers. Although this is not RFC compliant, it is commonly the case for spam messages originating from Asia. It was suggested on mimelib-devel that email should offer 'strict', 'ignore', and 'replace' modes for the programmer to decide what they want to do with invalid 8-bit data. This bug was discussed on the mimelib-devel list. See the thread starting at: http://article.gmane.org/gmane.comp.python.mime.devel/199 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-14 19:47 Message: Logged In: YES user_id=12800 Phew! :) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-10-14 19:05 Message: Logged In: YES user_id=85984 Upgrading to email 2.4.3 solved this problem. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621457&group_id=5470 From noreply@sourceforge.net Tue Oct 15 00:49:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 16:49:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-622953 ] import order changes with freeze Message-ID: Bugs item #622953, was opened at 2002-10-14 06:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None >Priority: 3 Submitted By: Pim Buurman (pimbuur) Assigned to: Nobody/Anonymous (nobody) Summary: import order changes with freeze Initial Comment: When you have simple .py files in packages, when you do: from mainp.subp import submod both mainp and mainp.subp are imported, i.e. mainp.__init__.py and mainp.subp.__init__.py are interpreted. If you have frozen the package (Tools/freeze), mainp.subp.submod is found at once, and mainp and mainp.subp are not imported. This breaks the code for more complex situations, where the __init__ does contain vital initialization code. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:49 Message: Logged In: YES user_id=6380 I tried to reproduce this, but did not get the result you claim. I put "print __file__, __name__" in each of mainp/__init__.py, mainp/subp/__init__.py, and mainp/subp/submod.py. Then I freeze a module that contains "from mainp.subp import submod". This prints: mainp mainp.subp mainp.subp.submod Perhaps you dod something else wrong? How did you invoke freeze.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 From noreply@sourceforge.net Tue Oct 15 00:54:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 16:54:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-622849 ] inconsistent results of leading whitespace in textwrap input Message-ID: Bugs item #622849, was opened at 2002-10-14 01:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Greg Ward (gward) Summary: inconsistent results of leading whitespace in textwrap input Initial Comment: >>> x = TextWrapper() >>> x.wrap('This is a sentence that will not wrap') ['This is a sentence that will not wrap'] >>> x.wrap(' This is a sentence that will not wrap') [' This is a sentence that will not wrap'] >>> x.wrap('This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] >>> x.wrap(' This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] To me, this looks like a bug. It violates POLA, anyway (took me a while to figure out why one paragraph and only one paragraph in my output was indented more than the rest). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:54 Message: Logged In: YES user_id=6380 You always want the leading space to disappear, right? Then the easiest fix is to get rid of an optimization in wrap(): delete these two lines if len(text) + len(indent) <= self.width: return [indent + text] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 From noreply@sourceforge.net Tue Oct 15 00:57:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 16:57:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-622042 ] httplib HEAD request fails - keepalive Message-ID: Bugs item #622042, was opened at 2002-10-11 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) >Assigned to: Jeremy Hylton (jhylton) Summary: httplib HEAD request fails - keepalive Initial Comment: httplib fails to handle HEAD requests correctly when the server side honors a keep-alive connection. Per RFC2616, sect. 9.4: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in the response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This means that HEAD requests are likely to return a non-zero Content-Length, but with no body. The attached script, if called against an HTTP/1.1, keep-alive-aware server (try www.microsoft.com or www.redhat.com) will hang instead of finishing, because read() will expect to read some bytes from the connection. The script was tested against version 1.66 of httplib (the current HEAD). HTTP/1.0 and Connection: close (with HTTP/1.1) work as expected because the server closes the connection. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:57 Message: Logged In: YES user_id=6380 Sure seems that way. ;-( For example this hangs: python2.3 http-request.py python.org while this returns correctly: python2.3 http-request.py zope.com Mihai, do you have a proposed fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 From noreply@sourceforge.net Tue Oct 15 00:57:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 16:57:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-622953 ] import order changes with freeze Message-ID: Bugs item #622953, was opened at 2002-10-14 06:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 3 Submitted By: Pim Buurman (pimbuur) >Assigned to: Guido van Rossum (gvanrossum) Summary: import order changes with freeze Initial Comment: When you have simple .py files in packages, when you do: from mainp.subp import submod both mainp and mainp.subp are imported, i.e. mainp.__init__.py and mainp.subp.__init__.py are interpreted. If you have frozen the package (Tools/freeze), mainp.subp.submod is found at once, and mainp and mainp.subp are not imported. This breaks the code for more complex situations, where the __init__ does contain vital initialization code. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:49 Message: Logged In: YES user_id=6380 I tried to reproduce this, but did not get the result you claim. I put "print __file__, __name__" in each of mainp/__init__.py, mainp/subp/__init__.py, and mainp/subp/submod.py. Then I freeze a module that contains "from mainp.subp import submod". This prints: mainp mainp.subp mainp.subp.submod Perhaps you dod something else wrong? How did you invoke freeze.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 From noreply@sourceforge.net Tue Oct 15 01:21:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 17:21:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-622849 ] inconsistent results of leading whitespace in textwrap input Message-ID: Bugs item #622849, was opened at 2002-10-13 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Greg Ward (gward) Summary: inconsistent results of leading whitespace in textwrap input Initial Comment: >>> x = TextWrapper() >>> x.wrap('This is a sentence that will not wrap') ['This is a sentence that will not wrap'] >>> x.wrap(' This is a sentence that will not wrap') [' This is a sentence that will not wrap'] >>> x.wrap('This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] >>> x.wrap(' This is a sentence that will wrap because I have added a bunch of words to it until it is longer than 70 chars.') ['This is a sentence that will wrap because I have added a bunch of', 'words to it until it is longer than 70 chars.'] To me, this looks like a bug. It violates POLA, anyway (took me a while to figure out why one paragraph and only one paragraph in my output was indented more than the rest). ---------------------------------------------------------------------- >Comment By: R. David Murray (rdmurray) Date: 2002-10-14 16:21 Message: Logged In: YES user_id=100308 I don't care which it does, as long as it is consistent. And whichever it does probably ought to be documented . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 15:54 Message: Logged In: YES user_id=6380 You always want the leading space to disappear, right? Then the easiest fix is to get rid of an optimization in wrap(): delete these two lines if len(text) + len(indent) <= self.width: return [indent + text] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622849&group_id=5470 From noreply@sourceforge.net Tue Oct 15 01:35:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 17:35:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-621548 ] Numerous defunct threads left behind Message-ID: Bugs item #621548, was opened at 2002-10-10 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Jamin W. Collins (jamincollins) Assigned to: Nobody/Anonymous (nobody) Summary: Numerous defunct threads left behind Initial Comment: I originally noticed this problem with Debian's OfflineIMAP package and filed a report there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=162369 The short of it is that when running offlineimap for an extended period of time it will eventually leave a large number of defunct threads behind that eventually use up all available system processes. Killing the original offlineimap thread clears the problem for a while. The Debian maintainer of OfflineIMAP referred this over to the python maintainer, who in turn has asked (as you can see from the link above) that I file a report here. If there is any more information I can provide (beyond that in the Debian case already) please let me know. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:35 Message: Logged In: YES user_id=6380 I agree with Martin von Loewis - this does not appear to be a Python bug. When a Python thread exits, it does not show up in the ps listing as ; that to me suggests that there *is* some forking going on, perhaps under the guise of system() or popen(); or perhaps there's a bug in the C library's thread support. Lowering the priority as a result. I'll try to followup in the Debian thread as well, if there's a web interface. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 07:05 Message: Logged In: YES user_id=21627 The analysis that this is a Python bug is most likely wrong. You write > a number of defunct/zombie processes are spawned. then John Goerzen writes > It is likely, in any case, that this is a bug in Python itself. The > OfflineIMAP program does not fork However, John later points out that there are many threads used in this package. Please understand that threads show up as processes in Linux ps(1). IOW, what you are seeing are the many threads, not any additional processes. It appears that the system is waiting for somebody to call pthread_join. This should not be necessary, since Python invokes pthread_detach for all of its threads. So if the system does not reclaim terminated threads, it seems there is a bug in your C library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621548&group_id=5470 From noreply@sourceforge.net Tue Oct 15 01:42:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 17:42:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 15:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) Assigned to: Nobody/Anonymous (nobody) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:42 Message: Logged In: YES user_id=6380 idiscovery, can you mail me a patch? ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 16:10 Message: Logged In: YES user_id=626964 Forgot the case with no selection: def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: if len(x) > 0: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 15:57 Message: Logged In: YES user_id=626964 You are right. How would this look? def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-10-11 13:14 Message: Logged In: YES user_id=33229 You're right - there should be values returned. Ideally, getselection should return a Python list, not just a Tcl string which is a list to Tcl. Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Tue Oct 15 01:43:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 17:43:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-620783 ] SocketServer/socket allow_reuse_address Message-ID: Bugs item #620783, was opened at 2002-10-09 10:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Pat Notz (notz) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer/socket allow_reuse_address Initial Comment: The SocketServer.TCPServer.server_bind() method contains the following code: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) On SunOS and Linux (possibly others) this only appears to work if the third argument is changed to "2". Perhaps this is also a bug with the lower-level socket package's setsockopt() function (I mean, perhaps it *should* work with a value of "1"). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 16:43 Message: Logged In: YES user_id=6380 Are you sure about Linux? I've used this code successfully on Linux with '1'. Can you point to documentation that prove your point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 From noreply@sourceforge.net Tue Oct 15 01:51:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 17:51:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-620630 ] distutils mixed stdin/stdout output Message-ID: Bugs item #620630, was opened at 2002-10-09 02:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: distutils mixed stdin/stdout output Initial Comment: If distutils output is piped to a common logfile, the output is garbled as shown in: http://buildd.debian.org/fetch.php?&pkg=python-numeric&ver=22.0-2&arch=powerpc&stamp=1034115818&file=log&as=raw It's a bit confusing to search errors in the garbled output. It would be nice, if distutils flashes the output buffers on each newline. Not sure how well this shows in the included snippets. gcc-3.2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude -IPackages/FFSrc/ranlibmodule.c: In function `get_continuous_random': [here in the middle of the line] Src/ranlibmodule.c:47: warning: function declaration isn't a prototype Src/lapack_litemodule.c:649: warning: `lapack_liteError' defined but not used [upto here a compile command, then two other commands succeed, then the error for the link command] /usr/bin/ld: cannot find -lg2c-pic collect2: ld returned 1 exit status [and now the link command:] gcc-3.2 -shared build/temp.linux-ppc-2.3/lapack_litemodule.o -llapack -lblas -lg2c-pic -o build/lib.linux-ppc-2.3/lapack_lite.so error: command 'gcc-3.2' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:51 Message: Logged In: YES user_id=6380 The only way to turn on unbuffered output is to use python -u... I can't interpret the output you quote above; and the word "ranlibmodule.c" doesn't occur on the URL you mention; so I'm not sure what the relationship between the two is. I know very little of distutils. It seems it uses spawn() to run subcommands, which uses fork+exec. The buffering set by distutils for itself doesn't affect the buffering of the subcommands. Perhaps you could suggest a patch? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-10-12 03:44 Message: Logged In: YES user_id=60903 Sure, but then I'll have to change the packaging of about 100 python packages for Debian. The distutils docs talk about "python setup.py", not "python -u setup.py". Can distutils turn on unbuffered output by default? Is there a real performance penalty using distutils with unbuffered output? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 12:16 Message: Logged In: YES user_id=31392 If you're piping the output to a combined log file, you can use python -u to unbuffer stdout. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620630&group_id=5470 From noreply@sourceforge.net Tue Oct 15 01:57:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 17:57:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-620179 ] __ipow__ broken for new-style classes Message-ID: Bugs item #620179, was opened at 2002-10-08 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Guido van Rossum (gvanrossum) Summary: __ipow__ broken for new-style classes Initial Comment: class NewKlass(object): def __ipow__(self, i): self._ipow = i return self obj = NewKlass() obj **= 1 TypeError: __ipow__() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:57 Message: Logged In: YES user_id=6380 Fixed in 2.3. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-13 10:14 Message: Logged In: YES user_id=6380 Whoops, you're right. This was there since 2.2. Unfortunately "fixing" this means broken code that would have worked before, so I won't fix it in 2.2.2; I'll fix it in 2.3 though. Workaround; declare __ipow__ with an *optional* dummy extra argument, defaulting to None (it will only be called with None in that position anyway): def __ipow__(self, i, arg=None): ... This provides you with forward compatibility in 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620179&group_id=5470 From noreply@sourceforge.net Tue Oct 15 04:03:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Oct 2002 20:03:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-620783 ] SocketServer/socket allow_reuse_address Message-ID: Bugs item #620783, was opened at 2002-10-09 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 Category: Python Library Group: None >Status: Deleted Resolution: None Priority: 2 Submitted By: Pat Notz (notz) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer/socket allow_reuse_address Initial Comment: The SocketServer.TCPServer.server_bind() method contains the following code: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) On SunOS and Linux (possibly others) this only appears to work if the third argument is changed to "2". Perhaps this is also a bug with the lower-level socket package's setsockopt() function (I mean, perhaps it *should* work with a value of "1"). ---------------------------------------------------------------------- >Comment By: Pat Notz (notz) Date: 2002-10-15 03:03 Message: Logged In: YES user_id=8764 I can no longer reproduce the problem and a value of "1" seems to work again. When I get the chance I'll pull an old copy of our code out of CVS and try harder to reproduce it but I'm now thinking that it must have been a different issue with our code. I feel dumb, but I honestly remember testing this and doing so in front of others. Sorry for the inconvenience. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:43 Message: Logged In: YES user_id=6380 Are you sure about Linux? I've used this code successfully on Linux with '1'. Can you point to documentation that prove your point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620783&group_id=5470 From noreply@sourceforge.net Tue Oct 15 10:54:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 02:54:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Tue Oct 15 14:44:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 06:44:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-622042 ] httplib HEAD request fails - keepalive Message-ID: Bugs item #622042, was opened at 2002-10-11 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: httplib HEAD request fails - keepalive Initial Comment: httplib fails to handle HEAD requests correctly when the server side honors a keep-alive connection. Per RFC2616, sect. 9.4: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in the response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This means that HEAD requests are likely to return a non-zero Content-Length, but with no body. The attached script, if called against an HTTP/1.1, keep-alive-aware server (try www.microsoft.com or www.redhat.com) will hang instead of finishing, because read() will expect to read some bytes from the connection. The script was tested against version 1.66 of httplib (the current HEAD). HTTP/1.0 and Connection: close (with HTTP/1.1) work as expected because the server closes the connection. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2002-10-15 09:44 Message: Logged In: YES user_id=205865 Yes, I will upload the patch as soon as possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:57 Message: Logged In: YES user_id=6380 Sure seems that way. ;-( For example this hangs: python2.3 http-request.py python.org while this returns correctly: python2.3 http-request.py zope.com Mihai, do you have a proposed fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 From noreply@sourceforge.net Tue Oct 15 15:18:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 07:18:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-484967 ] bad links at Ref Guide Message-ID: Bugs item #484967, was opened at 2001-11-23 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None >Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad links at Ref Guide Initial Comment: There are broken links and bad formed urls at a couple of html files in the Ref manual. On file: Doc/ref/atom-literals.html node20.html#tok-stringliteral node23.html#tok-longinteger On file: Doc/ref/integers.html <> Are the same problems as the #217195 bug report? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-15 10:18 Message: Logged In: YES user_id=3066 Raising the priority since this is a recurring issue for people, and we get a regular stream of messages to python-docs and webmaster about this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 14:38 Message: Logged In: YES user_id=593130 The pages are different but the symptoms certainly look the same: some links are good, some aren't because they use old 'node##' names instead of newer names. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 16:45 Message: Logged In: YES user_id=3066 These are definately different from bug #217195. ;-( ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2001-11-23 14:47 Message: Logged In: YES user_id=112690 "nobody/anonymous" was me: Hernan Foffani. :-) and the errors are in python 2.2b2 docs (windows distrib) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470 From noreply@sourceforge.net Tue Oct 15 16:22:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 08:22:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Tue Oct 15 17:03:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 09:03:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-622042 ] httplib HEAD request fails - keepalive Message-ID: Bugs item #622042, was opened at 2002-10-11 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: httplib HEAD request fails - keepalive Initial Comment: httplib fails to handle HEAD requests correctly when the server side honors a keep-alive connection. Per RFC2616, sect. 9.4: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in the response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This means that HEAD requests are likely to return a non-zero Content-Length, but with no body. The attached script, if called against an HTTP/1.1, keep-alive-aware server (try www.microsoft.com or www.redhat.com) will hang instead of finishing, because read() will expect to read some bytes from the connection. The script was tested against version 1.66 of httplib (the current HEAD). HTTP/1.0 and Connection: close (with HTTP/1.1) work as expected because the server closes the connection. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2002-10-15 12:03 Message: Logged In: YES user_id=205865 Not necessarily the best approach, but it does fix the problem. The library already special-case some return codes that guarantee the body is always zero-length. Signalling that HEAD requests need the same punishment is all it takes. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2002-10-15 09:44 Message: Logged In: YES user_id=205865 Yes, I will upload the patch as soon as possible. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:57 Message: Logged In: YES user_id=6380 Sure seems that way. ;-( For example this hangs: python2.3 http-request.py python.org while this returns correctly: python2.3 http-request.py zope.com Mihai, do you have a proposed fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622042&group_id=5470 From noreply@sourceforge.net Tue Oct 15 19:00:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 11:00:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-623669 ] __rdiv__ vs new-style classes Message-ID: Bugs item #623669, was opened at 2002-10-15 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 Category: Type/class unification Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: __rdiv__ vs new-style classes Initial Comment: In 2.2.2 and 2.3, consider this: """ class F: def __init__(self): print 'built an F' def __div__(self, other): print 'in F.__div__' return F() def __rdiv__(self, other): print 'in F.__rdiv__' return F() / self class F2(F): def __init__(self): print 'built an F2' 3 / F2() """ This displays what I expect: """ built an F2 in F.__rdiv__ built an F in F.__div__ built an F """ However, change F to derive from object: class F(object): and it's in infinite recursion, starting like so: """ built an F2 in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ ... """ Despite that F.__rdiv__ creates an explicit F() instance and uses it on the LHS of /, F.__div__ is never invoked; instead the RHS F2.__rdiv__ == F.__rdiv__ always gets the nod. Maybe this is intentional? I confess I've lost track of the rules. Changing the end of F.__rdiv__ to return F().__div__(self) brute-forces the desired outcome, so there is a workaround. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 From noreply@sourceforge.net Tue Oct 15 19:21:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 11:21:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-07 09:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Piers Lauder (pierslauder) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- >Comment By: John Goerzen (jgoerzen) Date: 2002-10-15 13:21 Message: Logged In: YES user_id=491567 I am attaching a full logfile from OfflineIMAP 3.99.1 that demonstrates this problem. It uses imaplib with Debug = 5. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-10-11 06:28 Message: Logged In: YES user_id=196212 Certainly the wrong behaviour! In order to nail down the source of the problem, would you kindly run "imaplib.py -d5 ..." in a way that demontrates the bug and email me with the entire output? (Send it to ) That should make clear why the code that deals with the {nnn} form isn't picking this up. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Tue Oct 15 22:47:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 14:47:43 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-623782 ] os.utime() that works on symlinks? Message-ID: Feature Requests item #623782, was opened at 2002-10-15 21:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=623782&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rob Landley (landley) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime() that works on symlinks? Initial Comment: I can query a symlink's timestamps with os.lstat(), but can't set them. Any attempt to set the timestamps on a symlink is transparently redirected to the file it points to (which in this case is on a read-only partition, as is not what I want to do anyway). Maybe os.lutime()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=623782&group_id=5470 From noreply@sourceforge.net Tue Oct 15 23:10:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 15:10:25 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-623782 ] os.utime() that works on symlinks? Message-ID: Feature Requests item #623782, was opened at 2002-10-15 23:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=623782&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rob Landley (landley) Assigned to: Nobody/Anonymous (nobody) Summary: os.utime() that works on symlinks? Initial Comment: I can query a symlink's timestamps with os.lstat(), but can't set them. Any attempt to set the timestamps on a symlink is transparently redirected to the file it points to (which in this case is on a read-only partition, as is not what I want to do anyway). Maybe os.lutime()? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-10-16 00:10 Message: Logged In: YES user_id=45365 Is there a way to do this from a C program? os.utime() is simply a wrapper around the C library call of the same name, and I'm not aware of a lutime() on systems I'm familiar with... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=623782&group_id=5470 From noreply@sourceforge.net Wed Oct 16 07:24:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Oct 2002 23:24:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-08 00:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Piers Lauder (pierslauder) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2002-10-16 16:24 Message: Logged In: YES user_id=196212 Thanks for the log. The behaviour you are seeing is the correct one. If the response to a command returns a tuple instead of a string, then the tuple is in the form (head, data) - ie: in the same format as the response from a FETCH command. So, one needs to check for a tuple in the response, and if so, find the data in the second element of it. The philosophy of this module is that it always returns all the data returned by the server without processing it. I think the documentation is less than clear on this point so I'll beef it up. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2002-10-16 04:21 Message: Logged In: YES user_id=491567 I am attaching a full logfile from OfflineIMAP 3.99.1 that demonstrates this problem. It uses imaplib with Debug = 5. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-10-11 21:28 Message: Logged In: YES user_id=196212 Certainly the wrong behaviour! In order to nail down the source of the problem, would you kindly run "imaplib.py -d5 ..." in a way that demontrates the bug and email me with the entire output? (Send it to ) That should make clear why the code that deals with the {nnn} form isn't picking this up. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Wed Oct 16 11:01:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 03:01:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-624024 ] Broken link in local documentation. Message-ID: Bugs item #624024, was opened at 2002-10-16 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624024&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Victor V. Kryukov (vtail) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Broken link in local documentation. Initial Comment: Hi. Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 In my python local documentation, link 'Up: Python Documentation Index' in 'Global Module Index' leads to './' instead off '../index.html'. I suppose this is a bug. Thanks, Victor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624024&group_id=5470 From noreply@sourceforge.net Wed Oct 16 18:02:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 10:02:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-07 09:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Works For Me Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Piers Lauder (pierslauder) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- >Comment By: John Goerzen (jgoerzen) Date: 2002-10-16 12:02 Message: Logged In: YES user_id=491567 I disagree. First of all, I can see exactly zero rationale for forcing the implementing software to: 1. Filter out the empty strings -- what exactly is the point of having those in the returned value anyway? 2. Convert bracketed data separately. imaplib handles this for us for message bodies, why not for LIST results? This is inconsistent. 3. Check whether it's received a string or tuple, and handle it differently. Given all this work, imaplib is not providing any benefit over speaking IMAP directly. That defeats the whole purpose of having the library available in the first place. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-10-16 01:24 Message: Logged In: YES user_id=196212 Thanks for the log. The behaviour you are seeing is the correct one. If the response to a command returns a tuple instead of a string, then the tuple is in the form (head, data) - ie: in the same format as the response from a FETCH command. So, one needs to check for a tuple in the response, and if so, find the data in the second element of it. The philosophy of this module is that it always returns all the data returned by the server without processing it. I think the documentation is less than clear on this point so I'll beef it up. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2002-10-15 13:21 Message: Logged In: YES user_id=491567 I am attaching a full logfile from OfflineIMAP 3.99.1 that demonstrates this problem. It uses imaplib with Debug = 5. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-10-11 06:28 Message: Logged In: YES user_id=196212 Certainly the wrong behaviour! In order to nail down the source of the problem, would you kindly run "imaplib.py -d5 ..." in a way that demontrates the bug and email me with the entire output? (Send it to ) That should make clear why the code that deals with the {nnn} form isn't picking this up. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Wed Oct 16 20:14:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 12:14:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-624254 ] email 2.4.3 pkg mail header error Message-ID: Bugs item #624254, was opened at 2002-10-16 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624254&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: email 2.4.3 pkg mail header error Initial Comment: email 2.4.3 pkg bundled with python 2.2.2 deletes parts of mail header string. My python environment is; Python 2.2.2 (#1, Oct 15 2002, 14:20:16) [GCC 2.95.3 20010315 (release)] on sunos5 This is a test script which reads a mail and write it back; --- #!/usr/bin/env python import email import sys print email.message_from_file(sys.stdin) --- The input and output are supposed to be the same, except for unix header line and some formatting changes, but with several test cases they are different. I attached two test cases which show differences. 1. file mail1_errorpart_in and mail1_errorpart_out: Input file has 6 "Received:" headers. There are missing parts in the 4th and 5th 'Received:' headers. Others are fine. 2. file mail2_errorpart_in and mail2_errorpart_out: Input file has broken "Cc:" header. The script converts it without warning/error but the converted "Cc:" header deletes several addresses. I trimmed test mails just to show error headers. If you need the whole one for debugging, let me know at "inyeol.lee@ieee.org". Inyeol Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624254&group_id=5470 From noreply@sourceforge.net Wed Oct 16 23:30:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Oct 2002 15:30:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp Message-ID: Bugs item #619732, was opened at 2002-10-08 00:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: John Goerzen (jgoerzen) Assigned to: Piers Lauder (pierslauder) Summary: imaplib fails with literals in LIST resp Initial Comment: Hello, imaplib is behaving weirdly when a LIST response contains literals -- the {25} sort of syntax. I have encountered a server in the wild that returns the folder name part of the response as a literal. imaplib returns a different sort of result for the two cases. Consider this snippet from the imaplib debug log from a LIST response: DEBUG[imap]: 30:09.81 untagged_responses[LIST] => ['() "\\" Admin', ('() "\\" {19}', 'Admin\CamillaHansen') That is: result[0] = '() "\\" Admin' result[1] = ('() "\\" {19}', 'Admin\CamillaHansen') Yes, result[0] is a string, and result[1] is a *tuple*! And moreover, the tuple even contains the {19}. This is silly. Both are presenting the same data. Both should be returned the same way -- possibly as a tuple to start with. There is no reason that the client progrma should have to strip out the {19}, nor that it should have to check whether the data being returned is a string or a tuple. imaplib should do all the necessary processing internally. -- John ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2002-10-17 08:30 Message: Logged In: YES user_id=196212 Unfortunately, changing this aspect of imaplib would break all existing software that uses it. You should treat imaplib as a low-level module, and consider writing a wrapper class that implememts the behaviour you wish to see. Then submit the wrapper class for inclusion to the imaplib module. That way, people can migrate to the new interface when/if they wish. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2002-10-17 03:02 Message: Logged In: YES user_id=491567 I disagree. First of all, I can see exactly zero rationale for forcing the implementing software to: 1. Filter out the empty strings -- what exactly is the point of having those in the returned value anyway? 2. Convert bracketed data separately. imaplib handles this for us for message bodies, why not for LIST results? This is inconsistent. 3. Check whether it's received a string or tuple, and handle it differently. Given all this work, imaplib is not providing any benefit over speaking IMAP directly. That defeats the whole purpose of having the library available in the first place. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-10-16 16:24 Message: Logged In: YES user_id=196212 Thanks for the log. The behaviour you are seeing is the correct one. If the response to a command returns a tuple instead of a string, then the tuple is in the form (head, data) - ie: in the same format as the response from a FETCH command. So, one needs to check for a tuple in the response, and if so, find the data in the second element of it. The philosophy of this module is that it always returns all the data returned by the server without processing it. I think the documentation is less than clear on this point so I'll beef it up. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2002-10-16 04:21 Message: Logged In: YES user_id=491567 I am attaching a full logfile from OfflineIMAP 3.99.1 that demonstrates this problem. It uses imaplib with Debug = 5. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-10-11 21:28 Message: Logged In: YES user_id=196212 Certainly the wrong behaviour! In order to nail down the source of the problem, would you kindly run "imaplib.py -d5 ..." in a way that demontrates the bug and email me with the entire output? (Send it to ) That should make clear why the code that deals with the {nnn} form isn't picking this up. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470 From noreply@sourceforge.net Thu Oct 17 13:41:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 05:41:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-622953 ] import order changes with freeze Message-ID: Bugs item #622953, was opened at 2002-10-14 12:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 3 Submitted By: Pim Buurman (pimbuur) Assigned to: Guido van Rossum (gvanrossum) Summary: import order changes with freeze Initial Comment: When you have simple .py files in packages, when you do: from mainp.subp import submod both mainp and mainp.subp are imported, i.e. mainp.__init__.py and mainp.subp.__init__.py are interpreted. If you have frozen the package (Tools/freeze), mainp.subp.submod is found at once, and mainp and mainp.subp are not imported. This breaks the code for more complex situations, where the __init__ does contain vital initialization code. ---------------------------------------------------------------------- >Comment By: Pim Buurman (pimbuur) Date: 2002-10-17 14:41 Message: Logged In: YES user_id=157121 Sorry to bother you. I was calling too early. The frozen code works as expected. I had not registered my special module for doing vital initialization code, and silently ignored the import failure. Please close this bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-15 01:49 Message: Logged In: YES user_id=6380 I tried to reproduce this, but did not get the result you claim. I put "print __file__, __name__" in each of mainp/__init__.py, mainp/subp/__init__.py, and mainp/subp/submod.py. Then I freeze a module that contains "from mainp.subp import submod". This prints: mainp mainp.subp mainp.subp.submod Perhaps you dod something else wrong? How did you invoke freeze.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 From noreply@sourceforge.net Thu Oct 17 15:34:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 07:34:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-622953 ] import order changes with freeze Message-ID: Bugs item #622953, was opened at 2002-10-14 06:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Pim Buurman (pimbuur) Assigned to: Guido van Rossum (gvanrossum) Summary: import order changes with freeze Initial Comment: When you have simple .py files in packages, when you do: from mainp.subp import submod both mainp and mainp.subp are imported, i.e. mainp.__init__.py and mainp.subp.__init__.py are interpreted. If you have frozen the package (Tools/freeze), mainp.subp.submod is found at once, and mainp and mainp.subp are not imported. This breaks the code for more complex situations, where the __init__ does contain vital initialization code. ---------------------------------------------------------------------- Comment By: Pim Buurman (pimbuur) Date: 2002-10-17 08:41 Message: Logged In: YES user_id=157121 Sorry to bother you. I was calling too early. The frozen code works as expected. I had not registered my special module for doing vital initialization code, and silently ignored the import failure. Please close this bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 19:49 Message: Logged In: YES user_id=6380 I tried to reproduce this, but did not get the result you claim. I put "print __file__, __name__" in each of mainp/__init__.py, mainp/subp/__init__.py, and mainp/subp/submod.py. Then I freeze a module that contains "from mainp.subp import submod". This prints: mainp mainp.subp mainp.subp.submod Perhaps you dod something else wrong? How did you invoke freeze.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622953&group_id=5470 From noreply@sourceforge.net Thu Oct 17 16:46:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 08:46:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-624729 ] set __file__ in scripts Message-ID: Bugs item #624729, was opened at 2002-10-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624729&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: set __file__ in scripts Initial Comment: It would be good to make __file__ available in scripts as well as in modules when it's possible to do so. The idiomatic ways of determining the directory containing source code that is intended to be usable as either a module or a script is too often mis-typed, primarily because it's too long to remember easily. Note that in some cases, it is not possible to set __file__, but these are due to not using a named file directly: - python -c 'source code' - cat somefile.py | python For the record, the current cleanest way to do this seems to be: import os.path import sys try: __file__ except NameError: __file__ = sys.argv[0] SOURCEDIR = os.path.abspath(os.path.dirname(__file__)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624729&group_id=5470 From noreply@sourceforge.net Thu Oct 17 19:18:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 11:18:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-624807 ] sq_concat prevents __radd__ from working Message-ID: Bugs item #624807, was opened at 2002-10-17 18:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624807&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: sq_concat prevents __radd__ from working Initial Comment: See attached code 'bug.py'. What's happening is if the LHS of an inplace add has a sq_concat or sq_inplace_concat method but it cannot handle the RHS argument then the operation fails rather than trying __radd__. I think this is related to my str.__mod__ bug. Guido, I would appreciate any comments you have on fiixing this problem. Fixing this specific problem should be pretty straight forward but I suspect more tp_as_sequence vs. tp_as_number confusion exists. What's the the longterm strategy WRT sq_concat and sq_repeat? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624807&group_id=5470 From noreply@sourceforge.net Thu Oct 17 19:52:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 11:52:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-624827 ] Creation of struct_seq types Message-ID: Bugs item #624827, was opened at 2002-10-17 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Creation of struct_seq types Initial Comment: It would be really nice to be able to create structure sequence types from within Python. MvL suggested: ------------------- ... I think all you need to do is to expose PyStructSequence_InitType. I would recommend an interface like struct_seq(name, doc, n_in_sequence, (fields)) where fields is a list of (name,doc) tuples. You will need to temporarily allocate a PyStructSequence_Field array of len(fields)+1 elements, and put the PyStructSequence_Desc on the stack. You will also need to dynamically allocate a PyTypeObject which you return. I would put this into the new module. ------------------- Assigned to me since I actually wanted to create these things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470 From noreply@sourceforge.net Thu Oct 17 19:53:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 11:53:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-624807 ] sq_concat prevents __radd__ from working Message-ID: Bugs item #624807, was opened at 2002-10-17 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624807&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: sq_concat prevents __radd__ from working Initial Comment: See attached code 'bug.py'. What's happening is if the LHS of an inplace add has a sq_concat or sq_inplace_concat method but it cannot handle the RHS argument then the operation fails rather than trying __radd__. I think this is related to my str.__mod__ bug. Guido, I would appreciate any comments you have on fiixing this problem. Fixing this specific problem should be pretty straight forward but I suspect more tp_as_sequence vs. tp_as_number confusion exists. What's the the longterm strategy WRT sq_concat and sq_repeat? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-17 14:53 Message: Logged In: YES user_id=6380 Boy what a mess indeed! Most embarrassingly, this code worked in Python 2.0! :-( I'm not sure how to fix this (and have no time to really look into it), but I have a long-term comment. Long-term, at the C API level, the separate notions of "sequence repeat" and "sequence concat" should disappear, and instead "PyNumber_Multiply" and "PyNumber_Add" should be used. (PySequence_Repeat can stay as a shorthand that takes a C int rather than an object). In general, whenever two operations look the same at the python level, there should only be one C API to invoke that, not two. Other examples are PySequence_GetItem vs. PyObject_GetItem. As a transition, the built-in types should probably start supporting the more generic ops (so strings would support nb_add and nb_mul), and the generic API functions should look for the numeric ops before trying the sequence or mapping ops. (And also try the mapping ops before the -- more restrictive -- sequence ops.) Some of this is already going on, but it would be a good policy to try and fix all of this in 2.3. I expect it wouldn't break much -- you'd have to have a type that interprets e.g. sq_repeat different than nb_mul to get code breakage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624807&group_id=5470 From noreply@sourceforge.net Thu Oct 17 21:20:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 13:20:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-624860 ] help(UNICODE) -- reference page missing Message-ID: Bugs item #624860, was opened at 2002-10-17 20:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624860&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: help(UNICODE) -- reference page missing Initial Comment: Entering IDLE in 2.2.2 on Win2K: >>> help() help> topics Lists (among many others), UNICODE. Howver, help> UNICODE elicits the error: could not read docs from C:\PYTHON22\doc/ref/unicode.html It seemed the only entry in topics that did fail, but I am not certain this is so. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624860&group_id=5470 From noreply@sourceforge.net Thu Oct 17 21:45:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 13:45:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-624729 ] set __file__ in scripts Message-ID: Bugs item #624729, was opened at 2002-10-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624729&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Guido van Rossum (gvanrossum) Summary: set __file__ in scripts Initial Comment: It would be good to make __file__ available in scripts as well as in modules when it's possible to do so. The idiomatic ways of determining the directory containing source code that is intended to be usable as either a module or a script is too often mis-typed, primarily because it's too long to remember easily. Note that in some cases, it is not possible to set __file__, but these are due to not using a named file directly: - python -c 'source code' - cat somefile.py | python For the record, the current cleanest way to do this seems to be: import os.path import sys try: __file__ except NameError: __file__ = sys.argv[0] SOURCEDIR = os.path.abspath(os.path.dirname(__file__)) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-17 16:45 Message: Logged In: YES user_id=3066 Attached patch, assigned to Guido for review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624729&group_id=5470 From noreply@sourceforge.net Thu Oct 17 22:17:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 14:17:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-624893 ] pydoc shows tools/scripts but blows up Message-ID: Bugs item #624893, was opened at 2002-10-17 21:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624893&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc shows tools/scripts but blows up Initial Comment: pydoc (at least on win32 2.2.2) offers the tools/scripts files, but it blows up on several that are not prepared to be used as modules (including, I think, pydocgui, which may well be a special case). I suggest changing the scripts to use the "if __name__ == '__main__':" magic on those that blow up. Sorry I don't have a full list at the moment, I'll remedy that this weekend. Less vital, but still desirable, would be to do the same for those scripts, like byteyears, that perform some action and simply yield an error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624893&group_id=5470 From noreply@sourceforge.net Thu Oct 17 22:25:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 14:25:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-624729 ] set __file__ in scripts Message-ID: Bugs item #624729, was opened at 2002-10-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624729&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: set __file__ in scripts Initial Comment: It would be good to make __file__ available in scripts as well as in modules when it's possible to do so. The idiomatic ways of determining the directory containing source code that is intended to be usable as either a module or a script is too often mis-typed, primarily because it's too long to remember easily. Note that in some cases, it is not possible to set __file__, but these are due to not using a named file directly: - python -c 'source code' - cat somefile.py | python For the record, the current cleanest way to do this seems to be: import os.path import sys try: __file__ except NameError: __file__ = sys.argv[0] SOURCEDIR = os.path.abspath(os.path.dirname(__file__)) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-17 17:25 Message: Logged In: YES user_id=3066 Guido accepted this verbally, with the caveat that an existing __file__ should not be replaced. Committed as Python/pythonrun.c revision 2.168; updated patch attached here as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-17 16:45 Message: Logged In: YES user_id=3066 Attached patch, assigned to Guido for review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624729&group_id=5470 From noreply@sourceforge.net Thu Oct 17 22:30:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 14:30:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 05:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 >Category: Windows >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 17:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Thu Oct 17 22:31:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 14:31:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-624254 ] email 2.4.3 pkg mail header error Message-ID: Bugs item #624254, was opened at 2002-10-16 15:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624254&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email 2.4.3 pkg mail header error Initial Comment: email 2.4.3 pkg bundled with python 2.2.2 deletes parts of mail header string. My python environment is; Python 2.2.2 (#1, Oct 15 2002, 14:20:16) [GCC 2.95.3 20010315 (release)] on sunos5 This is a test script which reads a mail and write it back; --- #!/usr/bin/env python import email import sys print email.message_from_file(sys.stdin) --- The input and output are supposed to be the same, except for unix header line and some formatting changes, but with several test cases they are different. I attached two test cases which show differences. 1. file mail1_errorpart_in and mail1_errorpart_out: Input file has 6 "Received:" headers. There are missing parts in the 4th and 5th 'Received:' headers. Others are fine. 2. file mail2_errorpart_in and mail2_errorpart_out: Input file has broken "Cc:" header. The script converts it without warning/error but the converted "Cc:" header deletes several addresses. I trimmed test mails just to show error headers. If you need the whole one for debugging, let me know at "inyeol.lee@ieee.org". Inyeol Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624254&group_id=5470 From noreply@sourceforge.net Thu Oct 17 23:47:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 15:47:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-624936 ] missing functionality in shelve Message-ID: Bugs item #624936, was opened at 2002-10-17 18:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624936&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing functionality in shelve Initial Comment: "key in shelf" is unimplemented, attached patch adds __contains__ implementation and a brief note to the module docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624936&group_id=5470 From noreply@sourceforge.net Thu Oct 17 23:48:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 15:48:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-624936 ] missing functionality in shelve Message-ID: Bugs item #624936, was opened at 2002-10-17 18:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624936&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None >Priority: 1 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing functionality in shelve Initial Comment: "key in shelf" is unimplemented, attached patch adds __contains__ implementation and a brief note to the module docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624936&group_id=5470 From noreply@sourceforge.net Fri Oct 18 01:22:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 17:22:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-624982 ] Potential AV in slot_sq_item Message-ID: Bugs item #624982, was opened at 2002-10-17 16:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Potential AV in slot_sq_item Initial Comment: In slot_sq_item (in typeobject.c), if the 'func' returned from _Py_TypeLookup has a tp_descr_get method, this method is called and the result is stored in the func variable. However, this func value is never checked for NULL before being passed to PyObject_Call. Thus, if the tp_descr_get tries to raise a Python exception (by returning NULL), an access violation occurs when PyObject_Call dereferences the NULL func pointer. It appears from inspection of the latest version of typeobject.c (in CVS) that this bug is also present in Python 2.3. I actually ran into this with an extension type, but here's some very contrived Python code which will cause the AV: >>> class test(object): ... __getitem__ = property(lambda s: 1/0) ... >>> t = test() >>> for i in t: ... print i ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 From noreply@sourceforge.net Fri Oct 18 02:30:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 17 Oct 2002 18:30:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-624982 ] Potential AV in slot_sq_item Message-ID: Bugs item #624982, was opened at 2002-10-17 20:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Guido van Rossum (gvanrossum) Summary: Potential AV in slot_sq_item Initial Comment: In slot_sq_item (in typeobject.c), if the 'func' returned from _Py_TypeLookup has a tp_descr_get method, this method is called and the result is stored in the func variable. However, this func value is never checked for NULL before being passed to PyObject_Call. Thus, if the tp_descr_get tries to raise a Python exception (by returning NULL), an access violation occurs when PyObject_Call dereferences the NULL func pointer. It appears from inspection of the latest version of typeobject.c (in CVS) that this bug is also present in Python 2.3. I actually ran into this with an extension type, but here's some very contrived Python code which will cause the AV: >>> class test(object): ... __getitem__ = property(lambda s: 1/0) ... >>> t = test() >>> for i in t: ... print i ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 21:30 Message: Logged In: YES user_id=33168 I can confirm the code core dumps for 2.3. The attached patch against 2.3 corrects the problem for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 From noreply@sourceforge.net Fri Oct 18 09:20:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 01:20:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-623464 ] tempfile crashes Message-ID: Bugs item #623464, was opened at 2002-10-15 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile crashes Initial Comment: tempfile.NamedTemporaryFile(".zip") crashes with an access violation. Win2k, SP2. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-10-18 10:20 Message: Logged In: YES user_id=11105 It crashes in fdopen - looks like a bug in MS runtime library: (in file vc98\crt\src\fdopen.c) fdopen calls _tfopen(), creates a FILE *stream, and if the first character in mode is not r, w, or a, sets 'stream' to NULL to signal an error. Then it calls _unlock_str(stream), which crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 23:30 Message: Logged In: YES user_id=33168 Note: You probably want: tempfile.NamedTemporaryFile(suffix=".zip") I tried this under Linux and get: OSError: [Errno 22] Invalid argument So this appears to be windows specific. Exactly which line is causing the crash? os.fdopen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623464&group_id=5470 From noreply@sourceforge.net Fri Oct 18 09:58:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 01:58:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-624936 ] missing functionality in shelve Message-ID: Bugs item #624936, was opened at 2002-10-18 00:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624936&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 1 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing functionality in shelve Initial Comment: "key in shelf" is unimplemented, attached patch adds __contains__ implementation and a brief note to the module docstring. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-18 10:58 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as shelve.py 1.16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624936&group_id=5470 From noreply@sourceforge.net Fri Oct 18 13:36:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 05:36:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-624982 ] Potential AV in slot_sq_item Message-ID: Bugs item #624982, was opened at 2002-10-17 20:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Guido van Rossum (gvanrossum) Summary: Potential AV in slot_sq_item Initial Comment: In slot_sq_item (in typeobject.c), if the 'func' returned from _Py_TypeLookup has a tp_descr_get method, this method is called and the result is stored in the func variable. However, this func value is never checked for NULL before being passed to PyObject_Call. Thus, if the tp_descr_get tries to raise a Python exception (by returning NULL), an access violation occurs when PyObject_Call dereferences the NULL func pointer. It appears from inspection of the latest version of typeobject.c (in CVS) that this bug is also present in Python 2.3. I actually ran into this with an extension type, but here's some very contrived Python code which will cause the AV: >>> class test(object): ... __getitem__ = property(lambda s: 1/0) ... >>> t = test() >>> for i in t: ... print i ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-18 08:36 Message: Logged In: YES user_id=6380 Correct. Neal, would you mind checking this in for both 2.3 and 2.2? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 21:30 Message: Logged In: YES user_id=33168 I can confirm the code core dumps for 2.3. The attached patch against 2.3 corrects the problem for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 From noreply@sourceforge.net Fri Oct 18 15:40:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 07:40:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-484967 ] bad links at Ref Guide Message-ID: Bugs item #484967, was opened at 2001-11-23 14:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bad links at Ref Guide Initial Comment: There are broken links and bad formed urls at a couple of html files in the Ref manual. On file: Doc/ref/atom-literals.html node20.html#tok-stringliteral node23.html#tok-longinteger On file: Doc/ref/integers.html <> Are the same problems as the #217195 bug report? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-18 10:40 Message: Logged In: YES user_id=3066 Fixed by Neal Norwitz in Doc/tools/node2label.pl revisions 1.14 and 1.12.18.1. Thanks, Neal! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-15 10:18 Message: Logged In: YES user_id=3066 Raising the priority since this is a recurring issue for people, and we get a regular stream of messages to python-docs and webmaster about this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 14:38 Message: Logged In: YES user_id=593130 The pages are different but the symptoms certainly look the same: some links are good, some aren't because they use old 'node##' names instead of newer names. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 16:45 Message: Logged In: YES user_id=3066 These are definately different from bug #217195. ;-( ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2001-11-23 14:47 Message: Logged In: YES user_id=112690 "nobody/anonymous" was me: Hernan Foffani. :-) and the errors are in python 2.2b2 docs (windows distrib) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484967&group_id=5470 From noreply@sourceforge.net Fri Oct 18 15:44:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 07:44:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-217195 ] Broken \ref link in documentation Message-ID: Bugs item #217195, was opened at 2000-10-18 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Fixed 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: Fred L. Drake, Jr. (fdrake) Date: 2002-10-18 10:44 Message: Logged In: YES user_id=3066 Links fixed with a patch by Neal Norwitz in Doc/tools/node2label.pl revisions 1.14 and 1.12.18.1. This turned out not to be a LaTeX2HTML bug but a bug in our own re-naming script that we use to post-process the generated HTML (not surprising, but this was a question earlier). I'm marking this fixed but left open since this issue's comments include a request for additional cross-references in the language reference. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 12:42 Message: Logged In: YES user_id=593130 The page in question is '4.2 Exceptions' http://www.python.org/doc/current/ref/exceptions.html The line in question is: See also the description of the try statement in section 7.4 and raise statement in section 6.9. 6.9 links to '6.9 The raise statement' http://www.python.org/doc/current/ref/raise.html#raise which works fine 7.4 links to the now obsolete URL http://www.python.org/doc/current/ref/node83.html#try It should link to the current '7.4 The try statement ' http://www.python.org/doc/current/ref/try.html or maybe? http://www.python.org/doc/current/ref/try.html#try Isn't this a simple update so that the 7.4 ref works like the 6.9 ref? PS. I would like also like references from 7.4 to 4.2 and 6.9 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 17:32 Message: Logged In: YES user_id=31392 Was it a LaTeX2HTML bug or not? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-29 19:51 Message: Logged In: NO ergdfvgdfdfgsdgff ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-12-12 16: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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470 From noreply@sourceforge.net Fri Oct 18 16:23:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 08:23:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-217195 ] Broken \ref link in documentation Message-ID: Bugs item #217195, was opened at 2000-10-18 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Fixed 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: Fred L. Drake, Jr. (fdrake) Date: 2002-10-18 11:23 Message: Logged In: YES user_id=3066 Added additional cross-references in Doc/ref/ref6.tex revisions 1.56, 1.47.4.4, and Doc/ref/ref7.tex revisions 1.35, 1.29.8.6. Closing the report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-18 10:44 Message: Logged In: YES user_id=3066 Links fixed with a patch by Neal Norwitz in Doc/tools/node2label.pl revisions 1.14 and 1.12.18.1. This turned out not to be a LaTeX2HTML bug but a bug in our own re-naming script that we use to post-process the generated HTML (not surprising, but this was a question earlier). I'm marking this fixed but left open since this issue's comments include a request for additional cross-references in the language reference. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 12:42 Message: Logged In: YES user_id=593130 The page in question is '4.2 Exceptions' http://www.python.org/doc/current/ref/exceptions.html The line in question is: See also the description of the try statement in section 7.4 and raise statement in section 6.9. 6.9 links to '6.9 The raise statement' http://www.python.org/doc/current/ref/raise.html#raise which works fine 7.4 links to the now obsolete URL http://www.python.org/doc/current/ref/node83.html#try It should link to the current '7.4 The try statement ' http://www.python.org/doc/current/ref/try.html or maybe? http://www.python.org/doc/current/ref/try.html#try Isn't this a simple update so that the 7.4 ref works like the 6.9 ref? PS. I would like also like references from 7.4 to 4.2 and 6.9 ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 17:32 Message: Logged In: YES user_id=31392 Was it a LaTeX2HTML bug or not? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-29 19:51 Message: Logged In: NO ergdfvgdfdfgsdgff ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-12-12 16: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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&group_id=5470 From noreply@sourceforge.net Fri Oct 18 17:46:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 09:46:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-624982 ] Potential AV in slot_sq_item Message-ID: Bugs item #624982, was opened at 2002-10-17 20:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Neal Norwitz (nnorwitz) Summary: Potential AV in slot_sq_item Initial Comment: In slot_sq_item (in typeobject.c), if the 'func' returned from _Py_TypeLookup has a tp_descr_get method, this method is called and the result is stored in the func variable. However, this func value is never checked for NULL before being passed to PyObject_Call. Thus, if the tp_descr_get tries to raise a Python exception (by returning NULL), an access violation occurs when PyObject_Call dereferences the NULL func pointer. It appears from inspection of the latest version of typeobject.c (in CVS) that this bug is also present in Python 2.3. I actually ran into this with an extension type, but here's some very contrived Python code which will cause the AV: >>> class test(object): ... __getitem__ = property(lambda s: 1/0) ... >>> t = test() >>> for i in t: ... print i ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 12:46 Message: Logged In: YES user_id=33168 Thanks! Checked in as: typeobject.c 2.185 and 2.126.4.28 test_descr.py 1.158 and 1.113.4.26 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-18 08:36 Message: Logged In: YES user_id=6380 Correct. Neal, would you mind checking this in for both 2.3 and 2.2? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-17 21:30 Message: Logged In: YES user_id=33168 I can confirm the code core dumps for 2.3. The attached patch against 2.3 corrects the problem for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624982&group_id=5470 From noreply@sourceforge.net Fri Oct 18 17:57:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 09:57:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-621511 ] Tix Checklist getselection getstatus bug Message-ID: Bugs item #621511, was opened at 2002-10-10 15:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 Category: Tkinter >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Kerry W. Clark (kerrywclark) >Assigned to: Neal Norwitz (nnorwitz) Summary: Tix Checklist getselection getstatus bug Initial Comment: The Tix Checklist widget commands getselection and getstatus always return "none" instead of a list of selected items. When looking at the /Lib/lib-tk/Tix.py both these routines are missing return statements: def getselection(self, mode='on'): '''Mode can be on, off, default''' self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): self.tk.call(self._w, 'getstatus', entrypath) When return statements are added these commands work as advertised: def getselection(self, mode='on'): '''Mode can be on, off, default''' return self.tk.call(self._w, 'getselection', mode) def getstatus(self, entrypath): return self.tk.call(self._w, 'getstatus', entrypath) This was seen in Python 2.2.1 but appears to be there for earlier releases as well. Is there a reason for this? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 12:57 Message: Logged In: YES user_id=33168 I've got mail from Mike Clarkson with other changes in Tix. I will sync up with Mike and fix this problem (he confirmed this is bug.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-14 20:42 Message: Logged In: YES user_id=6380 idiscovery, can you mail me a patch? ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 16:10 Message: Logged In: YES user_id=626964 Forgot the case with no selection: def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: if len(x) > 0: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Kerry W. Clark (kerrywclark) Date: 2002-10-11 15:57 Message: Logged In: YES user_id=626964 You are right. How would this look? def getselection(self, mode='on'): '''Mode can be on, off, default''' cnf = [] x = self.tk.call(self._w, 'getselection', mode) if string.find (x, ' ') == -1: cnf.append (x) else: cnf = list (self.tk.split(x)) return cnf ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-10-11 13:14 Message: Logged In: YES user_id=33229 You're right - there should be values returned. Ideally, getselection should return a Python list, not just a Tcl string which is a list to Tcl. Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621511&group_id=5470 From noreply@sourceforge.net Fri Oct 18 20:35:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 12:35:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerson Kurz (gersonkurz) >Assigned to: Jason Tishler (jlt63) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 15:35 Message: Logged In: YES user_id=33168 Jason can you shed any more light on this problem? Is this the same cygwin malloc problem or a new problem? ---------------------------------------------------------------------- Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-13 11:47 Message: Logged In: YES user_id=367261 It is the latest version of cygwin I know of, the cygwin1.dll is dated 2002-07-06 02:16. uname -a says CYGWIN_NT-5.0 DREIZEHN 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown so I guess its the 1.3.12 you mentioned. I can reproduce the crash using the following very simple script b = {} for i in range(900000): b[i] = [0] * 60 when I use range(900000), I get a crash. When I use range (800000), I see this Traceback (most recent call last): File "test2.py", line 3, in ? b[i] = [0] * 60 and then a crash. When I use (500000), it works. It smells like some 256mb limit or something; the memory for the process goes up to 264.000k which comes close, and then crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 21:43 Message: Logged In: YES user_id=33168 Do you know where python crashed? My guess was after a failed malloc. I tried testing this, but I don't have enough memory/cpu/patience to wait for loading such a large file. Can you make the test case smaller? What is the minimum size that still causes the seg fault? What version of cygwin? There is a known malloc problem in 1.3.12, see http://sources.redhat.com/ml/newlib/2002/msg00369.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Fri Oct 18 21:14:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 13:14:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 09:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerson Kurz (gersonkurz) Assigned to: Jason Tishler (jlt63) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-10-18 12:14 Message: Logged In: YES user_id=86216 Yes, this is the same Cygwin malloc problem. Gerson, please upgrade to Cygwin 1.3.13. IMO, the following is the easiest way to verify that the problem has been corrected: $ python -c 'import sys; list(xrange(sys.maxint / 4))' Traceback (most recent call last): File "", line 1, in ? MemoryError Gerson, please let me know if it's OK to close this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 11:35 Message: Logged In: YES user_id=33168 Jason can you shed any more light on this problem? Is this the same cygwin malloc problem or a new problem? ---------------------------------------------------------------------- Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-13 07:47 Message: Logged In: YES user_id=367261 It is the latest version of cygwin I know of, the cygwin1.dll is dated 2002-07-06 02:16. uname -a says CYGWIN_NT-5.0 DREIZEHN 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown so I guess its the 1.3.12 you mentioned. I can reproduce the crash using the following very simple script b = {} for i in range(900000): b[i] = [0] * 60 when I use range(900000), I get a crash. When I use range (800000), I see this Traceback (most recent call last): File "test2.py", line 3, in ? b[i] = [0] * 60 and then a crash. When I use (500000), it works. It smells like some 256mb limit or something; the memory for the process goes up to 264.000k which comes close, and then crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 17:43 Message: Logged In: YES user_id=33168 Do you know where python crashed? My guess was after a failed malloc. I tried testing this, but I don't have enough memory/cpu/patience to wait for loading such a large file. Can you make the test case smaller? What is the minimum size that still causes the seg fault? What version of cygwin? There is a known malloc problem in 1.3.12, see http://sources.redhat.com/ml/newlib/2002/msg00369.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Fri Oct 18 21:56:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 13:56:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-464405 ] freeze doesn't like DOS files on Linux Message-ID: Bugs item #464405, was opened at 2001-09-24 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 Category: Demos and Tools >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: freeze doesn't like DOS files on Linux Initial Comment: I've got a perfectly running Python program on Linux, importing some modules that were apparently written on Windows, since the files are in DOS format (carriage return + line feed at the end of lines). When I try to freeze this program, the module finder crashes on every module in DOS format claiming that there's a syntx error at the end of each line. This is not really serious, but quite annoying... Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 16:56 Message: Logged In: YES user_id=33168 I added "U" for the mode flag to open() for universal newlines. This fixed the problem. I modified Tools/freeze/modulefinder.py in run_script() and load_file() about lines 120 and 127. I didn't see any other open()s which seemed to need "U". Is that sufficient to close this bug? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-27 14:02 Message: Logged In: YES user_id=6380 I can reproduce this with Python 2.2 quite easily: on Linux, in the Tools/freeze directory, use the ../scripts/lfcr.py script to give hello.py CRLF line endings. Then try to freeze it. The cause is the code in the tokenizer that parses from strings, which doesn't like the \r\n line endings and doesn't throw the \r out like the code that parses from a file does. I'm tempted to request a feature that the tokenizer should be smarter when it finds a \r (e.g. just ignore it). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-09-26 15:51 Message: Logged In: YES user_id=21627 What Python version? Could you please submit an example of one of the files it is complaining about? Since you cannot attach it to this report, it would be good if you could open a new report. When doing so, please identify yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=464405&group_id=5470 From noreply@sourceforge.net Sat Oct 19 05:30:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 21:30:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-625509 ] Typo at line 351 of email/Charset.py Message-ID: Bugs item #625509, was opened at 2002-10-18 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625509&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Nobody/Anonymous (nobody) Summary: Typo at line 351 of email/Charset.py Initial Comment: The line should read "elif self.body_encoding is QP:", not "elif self.header_encoding is QP:'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625509&group_id=5470 From noreply@sourceforge.net Sat Oct 19 06:16:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 22:16:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Gerson Kurz (gersonkurz) Assigned to: Jason Tishler (jlt63) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- >Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-19 05:16 Message: Logged In: YES user_id=367261 you are right, it works with cygwin 1.3.13 - the allocation succeeds. you can close the bug report. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-10-18 20:14 Message: Logged In: YES user_id=86216 Yes, this is the same Cygwin malloc problem. Gerson, please upgrade to Cygwin 1.3.13. IMO, the following is the easiest way to verify that the problem has been corrected: $ python -c 'import sys; list(xrange(sys.maxint / 4))' Traceback (most recent call last): File "", line 1, in ? MemoryError Gerson, please let me know if it's OK to close this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 19:35 Message: Logged In: YES user_id=33168 Jason can you shed any more light on this problem? Is this the same cygwin malloc problem or a new problem? ---------------------------------------------------------------------- Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-13 15:47 Message: Logged In: YES user_id=367261 It is the latest version of cygwin I know of, the cygwin1.dll is dated 2002-07-06 02:16. uname -a says CYGWIN_NT-5.0 DREIZEHN 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown so I guess its the 1.3.12 you mentioned. I can reproduce the crash using the following very simple script b = {} for i in range(900000): b[i] = [0] * 60 when I use range(900000), I get a crash. When I use range (800000), I see this Traceback (most recent call last): File "test2.py", line 3, in ? b[i] = [0] * 60 and then a crash. When I use (500000), it works. It smells like some 256mb limit or something; the memory for the process goes up to 264.000k which comes close, and then crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 01:43 Message: Logged In: YES user_id=33168 Do you know where python crashed? My guess was after a failed malloc. I tried testing this, but I don't have enough memory/cpu/patience to wait for loading such a large file. Can you make the test case smaller? What is the minimum size that still causes the seg fault? What version of cygwin? There is a known malloc problem in 1.3.12, see http://sources.redhat.com/ml/newlib/2002/msg00369.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Sat Oct 19 07:24:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Oct 2002 23:24:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-619789 ] segmentation fault importing huge source Message-ID: Bugs item #619789, was opened at 2002-10-07 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 Category: Python Interpreter Core >Group: 3rd Party Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerson Kurz (gersonkurz) Assigned to: Jason Tishler (jlt63) Summary: segmentation fault importing huge source Initial Comment: I posted a problem with importing a very large sourcefile in python 2.2.1 to clp, see . Someone suggested that 2.3 would handle this situation much better, so I got the current version from CVS, built it with cygwin and tested it. That version raises a segmentation fault. The stackdump shows an ACCESS_VIOLATION somewhere inside python2.3.exe. You can download the source that causes this at http://p-nand-q.com/python/toobigfor2.3.zip but beware, the zipped source is 613k large (unzipped around 4.2 mb). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-19 02:24 Message: Logged In: YES user_id=31435 Marked 3rdParty and Fixed; was already Closed. Thanks for the followup, Gerson! ---------------------------------------------------------------------- Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-19 01:16 Message: Logged In: YES user_id=367261 you are right, it works with cygwin 1.3.13 - the allocation succeeds. you can close the bug report. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-10-18 16:14 Message: Logged In: YES user_id=86216 Yes, this is the same Cygwin malloc problem. Gerson, please upgrade to Cygwin 1.3.13. IMO, the following is the easiest way to verify that the problem has been corrected: $ python -c 'import sys; list(xrange(sys.maxint / 4))' Traceback (most recent call last): File "", line 1, in ? MemoryError Gerson, please let me know if it's OK to close this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 15:35 Message: Logged In: YES user_id=33168 Jason can you shed any more light on this problem? Is this the same cygwin malloc problem or a new problem? ---------------------------------------------------------------------- Comment By: Gerson Kurz (gersonkurz) Date: 2002-10-13 11:47 Message: Logged In: YES user_id=367261 It is the latest version of cygwin I know of, the cygwin1.dll is dated 2002-07-06 02:16. uname -a says CYGWIN_NT-5.0 DREIZEHN 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown so I guess its the 1.3.12 you mentioned. I can reproduce the crash using the following very simple script b = {} for i in range(900000): b[i] = [0] * 60 when I use range(900000), I get a crash. When I use range (800000), I see this Traceback (most recent call last): File "test2.py", line 3, in ? b[i] = [0] * 60 and then a crash. When I use (500000), it works. It smells like some 256mb limit or something; the memory for the process goes up to 264.000k which comes close, and then crashes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-10 21:43 Message: Logged In: YES user_id=33168 Do you know where python crashed? My guess was after a failed malloc. I tried testing this, but I don't have enough memory/cpu/patience to wait for loading such a large file. Can you make the test case smaller? What is the minimum size that still causes the seg fault? What version of cygwin? There is a known malloc problem in 1.3.12, see http://sources.redhat.com/ml/newlib/2002/msg00369.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619789&group_id=5470 From noreply@sourceforge.net Sat Oct 19 20:27:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 12:27:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 19:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Nobody/Anonymous (nobody) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Sat Oct 19 21:12:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 13:12:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-488184 ] import with undefineds can crash python Message-ID: Bugs item #488184, was opened at 2001-12-02 23:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: import with undefineds can crash python Initial Comment: Importing a module which references undefined externals, or which references libraries that fail initialization, can crash the interpreter. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-10-19 22:12 Message: Logged In: YES user_id=45365 This seems to have been fixed on OSX 10.2. The import of, say, Carbon.Win will now work fine. But: python will still exit (not crash, a clean exit) when you actually try to access the window manager if you don't have the right so I am keeping this bug open. I will try and find out if there's a way to detect this situation. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-11 11:01 Message: Logged In: YES user_id=45365 Apple was already aware of this bug, their bug number for it is #2806458. There is no workaround known, so we'll have to wait until it is fixed. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-12-06 23:56 Message: Logged In: YES user_id=45365 Unfortunately the fix I had in mind, adding the "return on error" flag to NSLinkModule(), is not good enough. Python crashes while the initialization routine for the dynamic library is running, and NSLinkModule also never gets control back, it seems. I now think this is definitely an Apple bug. Lowering the priority because of that, not because it's not important. I did find an easy way to reproduce the bug, though: "su" to someone else (not root, someone who can't access your window server) and import _Win or something similar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=488184&group_id=5470 From noreply@sourceforge.net Sat Oct 19 22:13:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 14:13:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Sat Oct 19 22:18:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 14:18:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-625728 ] sys.executable in applets Message-ID: Bugs item #625728, was opened at 2002-10-19 23:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625728&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: sys.executable in applets Initial Comment: In applets sys.executable is the interpreter in the applet. Running this will launch a second copy of the applet. As sys.executable is apparently often used to fire up external scripts with system() or popen() this isn't very useful right now (especially within the IDE!). It would be nice if sys.executable could be set to an interpreter that can be used for starting external scripts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625728&group_id=5470 From noreply@sourceforge.net Sat Oct 19 22:18:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 14:18:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 >Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Sat Oct 19 22:23:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 14:23:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-625734 ] IDE starts in / on OSX Message-ID: Bugs item #625734, was opened at 2002-10-19 23:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625734&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE starts in / on OSX Initial Comment: On OSX the IDE (the macho version) starts with / is the working directory. If you're trying out some code this may have interesting consequences. It may be a good idea to chdir() either to the users' home directory or the users' desktop folder if the IDE has been started from the finder (which can be deduced from the presence of the -psn_xxxx in sys.argv[1]). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625734&group_id=5470 From noreply@sourceforge.net Sun Oct 20 06:24:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Oct 2002 22:24:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-625823 ] missing names in telnetlib.py Message-ID: Bugs item #625823, was opened at 2002-10-20 01:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: missing names in telnetlib.py Initial Comment: The telnet RFC (854 -- http://www.faqs.org/rfcs/rfc854.html) details eleven constants for the telnet protocol that are not included in the telnetlib module. The attached patch adds them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625823&group_id=5470 From noreply@sourceforge.net Sun Oct 20 18:16:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 10:16:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-625734 ] IDE starts in / on OSX Message-ID: Bugs item #625734, was opened at 2002-10-19 23:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625734&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE starts in / on OSX Initial Comment: On OSX the IDE (the macho version) starts with / is the working directory. If you're trying out some code this may have interesting consequences. It may be a good idea to chdir() either to the users' home directory or the users' desktop folder if the IDE has been started from the finder (which can be deduced from the presence of the -psn_xxxx in sys.argv[1]). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2002-10-20 19:16 Message: Logged In: YES user_id=92689 Fixed in rev. 1.23 of Mac/Tools/IDE/PythonIDEMain.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625734&group_id=5470 From noreply@sourceforge.net Sun Oct 20 19:59:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 11:59:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-625509 ] Typo at line 351 of email/Charset.py Message-ID: Bugs item #625509, was opened at 2002-10-19 00:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625509&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Lawrence (lordsutch) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Typo at line 351 of email/Charset.py Initial Comment: The line should read "elif self.body_encoding is QP:", not "elif self.header_encoding is QP:'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625509&group_id=5470 From noreply@sourceforge.net Sun Oct 20 20:02:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 12:02:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 15:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 22:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 20:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 18:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 15:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply@sourceforge.net Sun Oct 20 20:25:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 12:25:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-620739 ] missing mappings in locale tables Message-ID: Bugs item #620739, was opened at 2002-10-09 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: missing mappings in locale tables Initial Comment: (via mail from Oleg Deribas) Here are two missed mappings in locale.py for russian and ukrainian languages: 0x0422: "uk_UA", # Ukrainian (Ukraine) 0x0419: "ru_RU", # Russian (Russia) locale_alias table also misses mapping for ukrainian: 'uk': 'uk_UA.CP1251', 'uk_uk': 'uk_UA.CP1251', Is it possible to include this in sources? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-20 21:25 Message: Logged In: YES user_id=21627 The problem with the OEMCP is more complex, given the chcp utility (i.e. that the console code page may vary from console to console), see patch 612627. So I don't think we should keep a database of OEM code pages. ---------------------------------------------------------------------- Comment By: Oleg Deribas (older) Date: 2002-10-20 21:02 Message: Logged In: YES user_id=281684 There is also problem with default charset on windows. It have different charsets for GUI and textmode (OEM and ANSI). So for Ukrainian it is 1251 and 866 codepages accordingly. And windows uses non-POSIX locale names like ukr_ukr.1251 instead of uk_UA.CP1251 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 19:38 Message: Logged In: YES user_id=21627 I withdraw my question on windows_locale. As for uk_uk, it appears to be completely bogus. The country code for the Ukraine is UA, not UK (this is semi-officially, i.e. IANA-assigned, the United Kingdom). As for associating CP1251 with them: I don't care; I find the whole notion of "getdefaultlocale" broken. People can also arrange their systems to use uk_UA with UTF-8 if they want to, or iso-8859-5 (although the latter is reportedly insufficient for Ukrainian). Fredrik, feel free to add whatever you think appropriate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-09 17:54 Message: Logged In: YES user_id=80475 In some non-python projects (found through a google search), uk_uk is an encoding alias for KOI8-U. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-09 14:55 Message: Logged In: YES user_id=21627 I'm sure many more are missing also, Microsoft has currently 143 language identifiers. Assuming this goes into windows_locale, why does it have a a codeset in it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470 From noreply@sourceforge.net Mon Oct 21 00:02:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 16:02:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Nobody/Anonymous (nobody) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Mon Oct 21 00:28:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 16:28:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None >Priority: 6 Submitted By: Kevin M. Turner (acapnotic) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 19:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Mon Oct 21 03:52:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 19:52:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-626172 ] crash using unicode latin1 single char Message-ID: Bugs item #626172, was opened at 2002-10-20 22:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626172&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: M.-A. Lemburg (lemburg) Summary: crash using unicode latin1 single char Initial Comment: The following code will crash python (also attached as file): try: for c in u'\xe2': c in 'g\xe2teau' except UnicodeError: pass The problem appears to be a double free. Ref count goes negative in a debug build. The problem is with the unicode_latin1 module variable. If I comment out the line unicode_latin1[*u] = unicode; in unicodeobject.c (~316 in CVS). Everything is fine. That obviously is not correct. I added another INCREF: Py_INCREF(unicode_latin1[*u]); That also fixed the crash. I'm not sure if the INCREF is the correct solution. This bug appeared on usenet: http://mail.python.org/pipermail/python-list/2002-October/127682.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626172&group_id=5470 From noreply@sourceforge.net Mon Oct 21 04:15:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 20:15:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-626172 ] crash using unicode latin1 single char Message-ID: Bugs item #626172, was opened at 2002-10-20 22:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626172&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: M.-A. Lemburg (lemburg) Summary: crash using unicode latin1 single char Initial Comment: The following code will crash python (also attached as file): try: for c in u'\xe2': c in 'g\xe2teau' except UnicodeError: pass The problem appears to be a double free. Ref count goes negative in a debug build. The problem is with the unicode_latin1 module variable. If I comment out the line unicode_latin1[*u] = unicode; in unicodeobject.c (~316 in CVS). Everything is fine. That obviously is not correct. I added another INCREF: Py_INCREF(unicode_latin1[*u]); That also fixed the crash. I'm not sure if the INCREF is the correct solution. This bug appeared on usenet: http://mail.python.org/pipermail/python-list/2002-October/127682.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 23:15 Message: Logged In: YES user_id=33168 A little more testing and neither of the fixes above corrects this one liner which crashes the interpreter: u'\xe2' in '\xe2' My latest suspicion is in PyUnicodeUCS2_DecodeASCII(), but I don't have enough time to debug this properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626172&group_id=5470 From noreply@sourceforge.net Mon Oct 21 06:12:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 22:12:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:12 Message: Logged In: YES user_id=12800 Is that url meant to point to the example code that illustrates the problem? If so, could you please upload it to this bug report instead. I'm not able to grab the file with wget. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 19:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Mon Oct 21 06:30:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 22:30:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-625509 ] Typo at line 351 of email/Charset.py Message-ID: Bugs item #625509, was opened at 2002-10-19 00:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625509&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Lawrence (lordsutch) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Typo at line 351 of email/Charset.py Initial Comment: The line should read "elif self.body_encoding is QP:", not "elif self.header_encoding is QP:'. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:30 Message: Logged In: YES user_id=12800 Fixed in Charset.py 1.11. However this isn't too big a problem at the moment, since we have no charsets for which header_encoding is QP but body_encoding is not. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625509&group_id=5470 From noreply@sourceforge.net Mon Oct 21 06:31:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 22:31:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-10-21 01:31 Message: Logged In: YES user_id=31435 I don't know what the URL has to do with this, but since I'm running on a modern OS I was able to get it for you . See attachment. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:12 Message: Logged In: YES user_id=12800 Is that url meant to point to the example code that illustrates the problem? If so, could you please upload it to this bug report instead. I'm not able to grab the file with wget. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 19:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Mon Oct 21 06:50:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 20 Oct 2002 22:50:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 19:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:50 Message: Logged In: YES user_id=12800 I have not idea what the url has to do with it either, but I was hoping it would be a simple example of "this code [that] broke when [he] upgraded python from 2.2.1 to 2.2.2". It doesn't appear to be, or at least it doesn't appear to be a simple boiled down example, and I'm too tired right now to slog through all this code. Kevin, can you please upload a simple, reproducible script illustrating the breakage? I'll look at it tomorrow, unless Insomniac Timbot beats me to it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-21 01:31 Message: Logged In: YES user_id=31435 I don't know what the URL has to do with this, but since I'm running on a modern OS I was able to get it for you . See attachment. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-21 01:12 Message: Logged In: YES user_id=12800 Is that url meant to point to the example code that illustrates the problem? If so, could you please upload it to this bug report instead. I'm not able to grab the file with wget. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 19:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Mon Oct 21 09:53:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 01:53:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-626119 ] email incompatibility upgrading to 2.2.2 Message-ID: Bugs item #626119, was opened at 2002-10-20 16:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 6 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email incompatibility upgrading to 2.2.2 Initial Comment: This code broke when I upgraded python from 2.2.1 to 2.2.2. Suddenly, my e-mail is base64 encoded, with no indication of this in the message header, so the message body shows up as garbage in my inbox. http://twistedmatrix.com/users/acapnotic/wares/code/E2Email/e2email-1.7.py I do get a warning: /home/kevint/bin/e2email:188: DeprecationWarning: _encoder argument is obsolete. but it just issues the warning in passing and doesn't stop it from eating my message. ---------------------------------------------------------------------- >Comment By: Kevin M. Turner (acapnotic) Date: 2002-10-21 01:53 Message: Logged In: YES user_id=9300 I can't debug as much as I'd like, as I don't have parallel installations of 2.2.1 and 2.2.2, but I'll see if I can at least trim that down for you by throwing out all the non-email-package related bits. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-20 22:50 Message: Logged In: YES user_id=12800 I have not idea what the url has to do with it either, but I was hoping it would be a simple example of "this code [that] broke when [he] upgraded python from 2.2.1 to 2.2.2". It doesn't appear to be, or at least it doesn't appear to be a simple boiled down example, and I'm too tired right now to slog through all this code. Kevin, can you please upload a simple, reproducible script illustrating the breakage? I'll look at it tomorrow, unless Insomniac Timbot beats me to it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-20 22:31 Message: Logged In: YES user_id=31435 I don't know what the URL has to do with this, but since I'm running on a modern OS I was able to get it for you . See attachment. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-20 22:12 Message: Logged In: YES user_id=12800 Is that url meant to point to the example code that illustrates the problem? If so, could you please upload it to this bug report instead. I'm not able to grab the file with wget. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-20 16:28 Message: Logged In: YES user_id=33168 Barry, I raised priority. This sounds like it could be important. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626119&group_id=5470 From noreply@sourceforge.net Mon Oct 21 11:30:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 03:30:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-626275 ] missing DECREF's in embedding example Message-ID: Bugs item #626275, was opened at 2002-10-21 12:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626275&group_id=5470 Category: Documentation Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: missing DECREF's in embedding example Initial Comment: Extending and Embedding Python, chapter 5.3 Pure Embedding There's a large example. I think there are some Py_DECREF's missing in the error handling cases: else { PyErr_Print(); fprintf(stderr, "Call failed\n"); return 1; } --> this one misses IMHO Py_DECREF(pArgs); Py_DECREF(pModule); Py_DECREF(pName); else { PyErr_Print(); fprintf(stderr, "Failed to load \%s\\n", argv[1]); return 1; } --> this one misses IMHO Py_DECREF(pName); I'm no Python expert, so I may be wrong - please check! If they're not necessary in these cases, you should perhaps add a comment explaining the reason to the docs... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626275&group_id=5470 From noreply@sourceforge.net Mon Oct 21 19:00:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 11:00:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-626452 ] Support RFC 2111 in email package Message-ID: Bugs item #626452, was opened at 2002-10-21 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626452&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support RFC 2111 in email package Initial Comment: Decide whether to support RFC 2111 in the email package. http://www.faqs.org/rfcs/rfc2111.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626452&group_id=5470 From noreply@sourceforge.net Mon Oct 21 21:42:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 13:42:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-568068 ] urllib needs 303/307 handlers Message-ID: Bugs item #568068, was opened at 2002-06-12 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568068&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: urllib needs 303/307 handlers Initial Comment: See http://mail.python.org/pipermail/python-dev/2002-June/025289.htm and http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html There is also an issue with the 302 handler (also discussed there). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-21 21:42 Message: Logged In: YES user_id=261020 Agreement seems to have been reached on this in the discussion of bug #549151. There is a patch there, but only the change to the 303 case should be applied, not 301. The docs need to state that 303 is automatically handled, too. Jeremy Hylton, from bug #549151: > I agree with your interpretation that urllib2 raise an > HTTPError to signal "request confirm" because an HTTPError > is also a valid response that the user could interpret. > But of urllib, an HTTP error doesn't contain a valid > response. The change would make it impossible for the > client to do anything if a 301 response is returned from a > POST. That seems worse than doing the wrong. John Lee, in reply: > As for urllib.py, I see the problem. 303 should still be > added, though, since that poses no problem at all. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568068&group_id=5470 From noreply@sourceforge.net Mon Oct 21 21:57:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 13:57:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh Message-ID: Bugs item #626543, was opened at 2002-10-21 21:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't do HTTP-EQUIV & Refresh Initial Comment: I just added support for HTML's META HTTP-EQUIV and zero-time Refresh HTTP headers to my 'ClientCookie' package (which exports essentially a clone of the urllib2 interface that knows about cookies, making use of urllib2 in the implementation). I didn't make a patch for urllib2 itself but it would be easy to do so. I don't plan to do this immediately, but will eventually (assuming Jeremy thinks it's advisible) -- I just wanted to register this fact to prevent duplication of effort. [BTW, this version of ClientCookie isn't on my web page yet -- my motherboard just died.] I'm sure you know this already, but: HTTP-EQUIV is just a way of putting headers in the HEAD section of an HTML document; Refresh is a Netscape 1.1 header that indicates that a browser should redirect after a specified time. Refresh headers with zero time act like redirections. The net result of the code I just wrote is that if you urlopen a URL that points to an HTML document like this: you're automatically redirected to "http://acme.com/new_url.htm". Same thing happens if the Refresh is in the HTTP headers, because all the HTTP-EQUIV headers are treated like real HTTP headers. Refresh with non-zero delay time is ignored (the urlopen returns the document body unchanged and does not redirect, but does still add the Refresh header to the HTTP headers). A few issues: 0) AFAIK, the Refresh header is not specified in any RFC, but only here: http://wp.netscape.com/assist/net_sites/pushpull.html (HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe earlier ones too) 1) Infinite loops should be detected, as for HTTP 30x? Presumably yes. 2) Should add HTTP-EQUIV headers to response object, or just treat them like headers internally? Perhaps it should be possible to get both behaviours? 3) Bug in my implementation: is greedy with reading body data from httplib's file object. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 From noreply@sourceforge.net Mon Oct 21 22:26:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 14:26:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-626554 ] __path__ is not documented Message-ID: Bugs item #626554, was opened at 2002-10-21 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626554&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __path__ is not documented Initial Comment: Except for a glancing mention (with no explanation) in the imp module, the __path__ module attribute is not documented in the language reference or library reference (as far as I was able to tell by using search engines). I think it ought to be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626554&group_id=5470 From noreply@sourceforge.net Mon Oct 21 22:59:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 14:59:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field Message-ID: Bugs item #626570, was opened at 2002-10-21 21:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael S. Fischer (otterley) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() always returns 0 in dst field Initial Comment: time.strptime() has always returned 0 in the Daylight Savings Time flag of the returned tuple. This leads to nasty bugs like the "off by an hour" bug revealed below: >>> strftime("%Y %b %d %H %M %S %Z", localtime(int(mktime(strptime("Oct 18 2002 00:00:00", "%b %d %Y %H:%M:%S"))))) '2002 Oct 18 01 00 00 PDT' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 From noreply@sourceforge.net Tue Oct 22 00:34:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 16:34:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field Message-ID: Bugs item #626570, was opened at 2002-10-21 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael S. Fischer (otterley) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() always returns 0 in dst field Initial Comment: time.strptime() has always returned 0 in the Daylight Savings Time flag of the returned tuple. This leads to nasty bugs like the "off by an hour" bug revealed below: >>> strftime("%Y %b %d %H %M %S %Z", localtime(int(mktime(strptime("Oct 18 2002 00:00:00", "%b %d %Y %H:%M:%S"))))) '2002 Oct 18 01 00 00 PDT' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-21 19:34 Message: Logged In: YES user_id=33168 Michael, what version(s) of Python does this effect? 2.2.2? 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 From noreply@sourceforge.net Tue Oct 22 00:43:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Oct 2002 16:43:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field Message-ID: Bugs item #626570, was opened at 2002-10-21 21:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael S. Fischer (otterley) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() always returns 0 in dst field Initial Comment: time.strptime() has always returned 0 in the Daylight Savings Time flag of the returned tuple. This leads to nasty bugs like the "off by an hour" bug revealed below: >>> strftime("%Y %b %d %H %M %S %Z", localtime(int(mktime(strptime("Oct 18 2002 00:00:00", "%b %d %Y %H:%M:%S"))))) '2002 Oct 18 01 00 00 PDT' ---------------------------------------------------------------------- >Comment By: Michael S. Fischer (otterley) Date: 2002-10-21 23:43 Message: Logged In: YES user_id=7820 I've seen it in 1.5.2, 2.1.3, 2.2 and 2.2.1. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-21 23:34 Message: Logged In: YES user_id=33168 Michael, what version(s) of Python does this effect? 2.2.2? 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 From noreply@sourceforge.net Tue Oct 22 16:36:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 08:36:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 17:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Tue Oct 22 16:54:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 08:54:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-626936 ] canvas.create_box() crashes Tk thread Message-ID: Bugs item #626936, was opened at 2002-10-22 15:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: T. Koehler (rasfahan) Assigned to: Nobody/Anonymous (nobody) Summary: canvas.create_box() crashes Tk thread Initial Comment: Frequently, but apparently not depending on the paramters passed, the following exception will be thrown, and Tk will stop responding while the interpreter continues to run. This is on Windows (95, 98, 2000), under linux, the problem does not occur. All parameters passed have int-values, we checked that first. The exception can be caught via a try-statement, but Tk will stop responding anyway. ---snip self.rectangle =self.canvas.create_rectangle(self.x,self.y+1,self.x2,self.y 2-1) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1961, in create_rectangle return self._create('rectangle', args, kw) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1939, in _create (self._w, 'create', itemType) ValueError: invalid literal for int(): None ---snap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 From noreply@sourceforge.net Tue Oct 22 18:03:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 10:03:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-626936 ] canvas.create_box() crashes Tk thread Message-ID: Bugs item #626936, was opened at 2002-10-22 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: T. Koehler (rasfahan) Assigned to: Nobody/Anonymous (nobody) Summary: canvas.create_box() crashes Tk thread Initial Comment: Frequently, but apparently not depending on the paramters passed, the following exception will be thrown, and Tk will stop responding while the interpreter continues to run. This is on Windows (95, 98, 2000), under linux, the problem does not occur. All parameters passed have int-values, we checked that first. The exception can be caught via a try-statement, but Tk will stop responding anyway. ---snip self.rectangle =self.canvas.create_rectangle(self.x,self.y+1,self.x2,self.y 2-1) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1961, in create_rectangle return self._create('rectangle', args, kw) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1939, in _create (self._w, 'create', itemType) ValueError: invalid literal for int(): None ---snap ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 19:03 Message: Logged In: YES user_id=21627 Can you please investigate this a little bit further? Split the return statement in _create into several parts command = (self._w, 'create', itemType) + args + \ self._options(cnf, kw) print command result = apply(self.tk.call, command) print result return getint(result) It seems that result will become None. This, in turn, is quite impossible: tk.app.call will never return None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 From noreply@sourceforge.net Tue Oct 22 18:04:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 10:04:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-626926 ] Build error using make VPATH feature Message-ID: Bugs item #626926, was opened at 2002-10-22 17:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Davide Di Blasi (davidedb) Assigned to: Nobody/Anonymous (nobody) Summary: Build error using make VPATH feature Initial Comment: PROBLEM DESCRIPTION ===================== After building successfully Python 2.2.2 from scratch on Solaris 8 using the usual commands (cd ~wrk/Python-2.2.2; ./configure; make), I decided to build it for multiple architectures (SunOS 5.6, 5.7 and 5.8), exploiting the supported VPATH feature of GNU make. Here are the commands I run for Solaris 6: 1. mkdir ~/wrk/Python-2.2.2/binaries/SunOS_5.6 2. cd ~/wrk/Python-2.2.2/binaries/SunOS_5.6 3. ../../configure -prefix=/usr/local/python 4. make Unfortunately the last command failed with the following error:... ranlib libpython2.2.a gcc -Xlinker --export-dynamic -o python \ Modules/python.o \ libpython2.2.a -lsocket -lnsl -ldl -lpthread -lthread -lm case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../../setup.py build;; \ esac running build running build_ext Traceback (most recent call last): File "../../setup.py", line 795, in ? main() File "../../setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "~wrk/Python-2.2.2/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "~wrk/Python-2.2.2/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "~wrk/Python-2.2.2/Lib/distutils/dist.py", line 913, in run_command cmd_obj.run() File "~wrk/Python-2.2.2/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "~wrk/Python-2.2.2/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/python/lib/python2.2/config/Makefile (No such file or directory) make: *** [sharedmods] Error 1 PROBLEM ANALYSIS================== By looking the code inside sysconfig.py module, it is clear that the problem is generated by the first IF clause (starting at line 32), where the python_build variable is set: the path obtained by joining "Lib" to the argv0_path variable does not exist, since no directory named Lib exists in the (current) work directory. In fact the only existing directories are: - Grammar - Modules - Objects - Parser - Python - build WORKAROUND ============= Simply create a link to the Lib directory provided with Python 2.2.2, i.e. in my example: ln -s ../../Lib make make test make install ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 19:04 Message: Logged In: YES user_id=21627 Would you like to work on a patch that fixes this problem? The patch should support both the case of in-place building, and VPATH building. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626926&group_id=5470 From noreply@sourceforge.net Tue Oct 22 19:30:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 11:30:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-622831 ] textwrap fails on unicode using defaults Message-ID: Bugs item #622831, was opened at 2002-10-14 00:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622831&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Greg Ward (gward) Summary: textwrap fails on unicode using defaults Initial Comment: I don't know if this is a module bug or a documentation bug. I'm using the documentation from the manual on python.org. >>> x = TextWrapper() >>> x.wrap(u'abcd') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/textwrap.py", line 239, in wrap text = self._munge_whitespace(text) File "/usr/local/lib/python2.3/textwrap.py", line 99, in _munge_whitespace text = text.translate(self.whitespace_trans) TypeError: character mapping must return integer, None or unicode If you do x.replace_whitespace = True, then it will wrap the text. So either whitespace replacement needs to be fixed, or the docs need to be updated to note that you have to set replace_whitespace to false if you want to wrap unicode. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2002-10-22 14:30 Message: Logged In: YES user_id=14422 I'm almost competely ignorant of Unicode, and so is textwrap.py. I'll try to get help on python-dev to fix this, or figure it out myself. Failing that, the inability to handle Unicode should be documented. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-14 08:48 Message: Logged In: YES user_id=21627 Greg, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=622831&group_id=5470 From noreply@sourceforge.net Tue Oct 22 21:21:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 13:21:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-606463 ] PyString_AsString underdocumented Message-ID: Bugs item #606463, was opened at 2002-09-08 17:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606463&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyString_AsString underdocumented Initial Comment: PyString_AsString() lacks a complete semantic description (can be done in terms of PyString_AsStringAndSize) or any description of what happens in case of error. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-22 16:21 Message: Logged In: YES user_id=3066 Clarified in Doc/api/concrete.tex revisions 1.18 and 1.6.6.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606463&group_id=5470 From noreply@sourceforge.net Tue Oct 22 21:26:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 13:26:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-624827 ] Creation of struct_seq types Message-ID: Bugs item #624827, was opened at 2002-10-17 14:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Creation of struct_seq types Initial Comment: It would be really nice to be able to create structure sequence types from within Python. MvL suggested: ------------------- ... I think all you need to do is to expose PyStructSequence_InitType. I would recommend an interface like struct_seq(name, doc, n_in_sequence, (fields)) where fields is a list of (name,doc) tuples. You will need to temporarily allocate a PyStructSequence_Field array of len(fields)+1 elements, and put the PyStructSequence_Desc on the stack. You will also need to dynamically allocate a PyTypeObject which you return. I would put this into the new module. ------------------- Assigned to me since I actually wanted to create these things. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-22 16:26 Message: Logged In: YES user_id=3066 As part of this, struct_seq types should be made subclassable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624827&group_id=5470 From noreply@sourceforge.net Tue Oct 22 22:02:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 14:02:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-626554 ] __path__ is not documented Message-ID: Bugs item #626554, was opened at 2002-10-21 17:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626554&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: R. David Murray (rdmurray) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __path__ is not documented Initial Comment: Except for a glancing mention (with no explanation) in the imp module, the __path__ module attribute is not documented in the language reference or library reference (as far as I was able to tell by using search engines). I think it ought to be. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-22 17:02 Message: Logged In: YES user_id=3066 Documented __path__ in Doc/tut/tut.tex revisions 1.174 and 1.156.4.1.2.13. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626554&group_id=5470 From noreply@sourceforge.net Tue Oct 22 22:59:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 14:59:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-623196 ] urllib.pathname2url(), .url2pathname() Message-ID: Bugs item #623196, was opened at 2002-10-14 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623196&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: urllib.pathname2url(), .url2pathname() Initial Comment: These two functions are not documented, nor do they have docstrings. This should be fixed. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-22 17:59 Message: Logged In: YES user_id=3066 Added documentation in Doc/lib/liburllib.tex revisions 1.44 and 1.40.8.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623196&group_id=5470 From noreply@sourceforge.net Tue Oct 22 23:42:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Oct 2002 15:42:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-626570 ] strptime() always returns 0 in dst field Message-ID: Bugs item #626570, was opened at 2002-10-21 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 Category: Python Library >Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael S. Fischer (otterley) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() always returns 0 in dst field Initial Comment: time.strptime() has always returned 0 in the Daylight Savings Time flag of the returned tuple. This leads to nasty bugs like the "off by an hour" bug revealed below: >>> strftime("%Y %b %d %H %M %S %Z", localtime(int(mktime(strptime("Oct 18 2002 00:00:00", "%b %d %Y %H:%M:%S"))))) '2002 Oct 18 01 00 00 PDT' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-22 18:42 Message: Logged In: YES user_id=33168 I'll have to look at this more. With 2.3, I get 00 00 00, with 1.5.2, 2.1.1, and 2.2.2, I get 01 00 00. The difference seems to be that the tm_isdst flag is set to -1 (mktime should guess) in 2.3, but the flag is set to 0 in other versions. It's possible this bug may not be able to be fixed due to backwards compatibility. ---------------------------------------------------------------------- Comment By: Michael S. Fischer (otterley) Date: 2002-10-21 19:43 Message: Logged In: YES user_id=7820 I've seen it in 1.5.2, 2.1.3, 2.2 and 2.2.1. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-21 19:34 Message: Logged In: YES user_id=33168 Michael, what version(s) of Python does this effect? 2.2.2? 2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626570&group_id=5470 From noreply@sourceforge.net Wed Oct 23 09:50:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 01:50:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-626172 ] crash using unicode latin1 single char Message-ID: Bugs item #626172, was opened at 2002-10-21 02:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626172&group_id=5470 Category: Unicode Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: M.-A. Lemburg (lemburg) Summary: crash using unicode latin1 single char Initial Comment: The following code will crash python (also attached as file): try: for c in u'\xe2': c in 'g\xe2teau' except UnicodeError: pass The problem appears to be a double free. Ref count goes negative in a debug build. The problem is with the unicode_latin1 module variable. If I comment out the line unicode_latin1[*u] = unicode; in unicodeobject.c (~316 in CVS). Everything is fine. That obviously is not correct. I added another INCREF: Py_INCREF(unicode_latin1[*u]); That also fixed the crash. I'm not sure if the INCREF is the correct solution. This bug appeared on usenet: http://mail.python.org/pipermail/python-list/2002-October/127682.html ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-23 08:50 Message: Logged In: YES user_id=38388 It's a bug in PyUnicode_Contains(). I'll check in a fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-21 03:15 Message: Logged In: YES user_id=33168 A little more testing and neither of the fixes above corrects this one liner which crashes the interpreter: u'\xe2' in '\xe2' My latest suspicion is in PyUnicodeUCS2_DecodeASCII(), but I don't have enough time to debug this properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626172&group_id=5470 From noreply@sourceforge.net Wed Oct 23 12:09:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 04:09:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-626936 ] canvas.create_box() crashes Tk thread Message-ID: Bugs item #626936, was opened at 2002-10-22 15:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: T. Koehler (rasfahan) Assigned to: Nobody/Anonymous (nobody) Summary: canvas.create_box() crashes Tk thread Initial Comment: Frequently, but apparently not depending on the paramters passed, the following exception will be thrown, and Tk will stop responding while the interpreter continues to run. This is on Windows (95, 98, 2000), under linux, the problem does not occur. All parameters passed have int-values, we checked that first. The exception can be caught via a try-statement, but Tk will stop responding anyway. ---snip self.rectangle =self.canvas.create_rectangle(self.x,self.y+1,self.x2,self.y 2-1) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1961, in create_rectangle return self._create('rectangle', args, kw) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1939, in _create (self._w, 'create', itemType) ValueError: invalid literal for int(): None ---snap ---------------------------------------------------------------------- >Comment By: T. Koehler (rasfahan) Date: 2002-10-23 11:09 Message: Logged In: YES user_id=634021 Ok, here's the output of the last two print-statements before the exception from getint(). To me it looks as if the tk.app.call actually did return None. ('.8476780.13726076.8520076', 'create', 'rectangle', 50, 3, 250, \ 13, '-fill', '#00FF00') None ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 17:03 Message: Logged In: YES user_id=21627 Can you please investigate this a little bit further? Split the return statement in _create into several parts command = (self._w, 'create', itemType) + args + \ self._options(cnf, kw) print command result = apply(self.tk.call, command) print result return getint(result) It seems that result will become None. This, in turn, is quite impossible: tk.app.call will never return None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 From noreply@sourceforge.net Wed Oct 23 14:40:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 06:40:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-626936 ] canvas.create_box() crashes Tk thread Message-ID: Bugs item #626936, was opened at 2002-10-22 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: T. Koehler (rasfahan) Assigned to: Nobody/Anonymous (nobody) Summary: canvas.create_box() crashes Tk thread Initial Comment: Frequently, but apparently not depending on the paramters passed, the following exception will be thrown, and Tk will stop responding while the interpreter continues to run. This is on Windows (95, 98, 2000), under linux, the problem does not occur. All parameters passed have int-values, we checked that first. The exception can be caught via a try-statement, but Tk will stop responding anyway. ---snip self.rectangle =self.canvas.create_rectangle(self.x,self.y+1,self.x2,self.y 2-1) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1961, in create_rectangle return self._create('rectangle', args, kw) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1939, in _create (self._w, 'create', itemType) ValueError: invalid literal for int(): None ---snap ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 15:40 Message: Logged In: YES user_id=21627 As I said, this is difficult to understand, since _tkinter has no return Py_None in the relevant code: it might be memory corruption in an completely unrelated module. Are you using any funny extension modules? Can you post a self-contained example that might allow me to reproduce the problem? Could you try to debug the associated C code in a debugger? I.e. set a breakpoint onto the single return in Tkapp_Call (the USING_OBJECTS version), and conditionalize it on res==Py_None. Then inspect the state of the Tcl interp. Sorry I can't be of more help. ---------------------------------------------------------------------- Comment By: T. Koehler (rasfahan) Date: 2002-10-23 13:09 Message: Logged In: YES user_id=634021 Ok, here's the output of the last two print-statements before the exception from getint(). To me it looks as if the tk.app.call actually did return None. ('.8476780.13726076.8520076', 'create', 'rectangle', 50, 3, 250, \ 13, '-fill', '#00FF00') None ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 19:03 Message: Logged In: YES user_id=21627 Can you please investigate this a little bit further? Split the return statement in _create into several parts command = (self._w, 'create', itemType) + args + \ self._options(cnf, kw) print command result = apply(self.tk.call, command) print result return getint(result) It seems that result will become None. This, in turn, is quite impossible: tk.app.call will never return None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 From noreply@sourceforge.net Wed Oct 23 14:54:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 06:54:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh Message-ID: Bugs item #626543, was opened at 2002-10-21 22:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't do HTTP-EQUIV & Refresh Initial Comment: I just added support for HTML's META HTTP-EQUIV and zero-time Refresh HTTP headers to my 'ClientCookie' package (which exports essentially a clone of the urllib2 interface that knows about cookies, making use of urllib2 in the implementation). I didn't make a patch for urllib2 itself but it would be easy to do so. I don't plan to do this immediately, but will eventually (assuming Jeremy thinks it's advisible) -- I just wanted to register this fact to prevent duplication of effort. [BTW, this version of ClientCookie isn't on my web page yet -- my motherboard just died.] I'm sure you know this already, but: HTTP-EQUIV is just a way of putting headers in the HEAD section of an HTML document; Refresh is a Netscape 1.1 header that indicates that a browser should redirect after a specified time. Refresh headers with zero time act like redirections. The net result of the code I just wrote is that if you urlopen a URL that points to an HTML document like this: you're automatically redirected to "http://acme.com/new_url.htm". Same thing happens if the Refresh is in the HTTP headers, because all the HTTP-EQUIV headers are treated like real HTTP headers. Refresh with non-zero delay time is ignored (the urlopen returns the document body unchanged and does not redirect, but does still add the Refresh header to the HTTP headers). A few issues: 0) AFAIK, the Refresh header is not specified in any RFC, but only here: http://wp.netscape.com/assist/net_sites/pushpull.html (HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe earlier ones too) 1) Infinite loops should be detected, as for HTTP 30x? Presumably yes. 2) Should add HTTP-EQUIV headers to response object, or just treat them like headers internally? Perhaps it should be possible to get both behaviours? 3) Bug in my implementation: is greedy with reading body data from httplib's file object. John ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 15:54 Message: Logged In: YES user_id=21627 In addition to the issues you have mentioned, there is also the backwards compatibility issue: Some applications might expect to get a meta-refresh document from urllib, then parse it and retry themselves. Those applications would break with such a change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 From noreply@sourceforge.net Wed Oct 23 14:58:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 06:58:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-621057 ] File write examples are inadequate Message-ID: Bugs item #621057, was opened at 2002-10-09 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Stagg (kandrew) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: File write examples are inadequate Initial Comment: The examples provided for writing to files in section 7.2 of the documentation are overly simple showing only writing of a static string. Reading through 7.1 (although not actually discussing file I/O) helps a little as the % operator is mentioned but the "...C sprintf()-style format string..." specifiers which are valid aren't cross referenced (and the 'Library Reference' is a largish search area). I had to find out experimentally that %f isn't valid although %d is. To date, I haven't been able to experimentally findout how to print a list or tuple. trying: file.write('"%s"', str(relatedMeasurements)) results in: TypeError: read-only buffer, tuple The addition of examples printing a list or tuple would be extremely helpful. Similarly, examples of using file.write() to produce print type output would be very illuminating. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-23 08:58 Message: Logged In: YES user_id=80475 Here are a few thoughts: The % formatting operator is fully documented in 2.2.6.2 of the library reference. I think the tutorial should be kept at an introductory level and the details left in the reference. OTOH, I agree that 2.2.6.2 is hard to find. %f is a valid format: '%f' % 3.14 There are several oddities in the file.write error in your post. First, the double quotes inside the single quotes (perhaps this is intentional). Second, the comma should have been the % formatting operator. Third, since 'file' is the name of a type, it is normally a good idea to pick another name like 'infil' or 'outfil'. The post doesn't include enough information to be able to reproduce the error. We need to know the value of relatedMeasurements and have a line showing how the file was opened. To debug the example, it would help to separate the concerns of file writing from the string formatting. Get the program to successfully format and print a string. Only then, add a line to write it out to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 From noreply@sourceforge.net Wed Oct 23 19:29:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 11:29:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-626936 ] canvas.create_box() crashes Tk thread Message-ID: Bugs item #626936, was opened at 2002-10-22 15:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: T. Koehler (rasfahan) Assigned to: Nobody/Anonymous (nobody) Summary: canvas.create_box() crashes Tk thread Initial Comment: Frequently, but apparently not depending on the paramters passed, the following exception will be thrown, and Tk will stop responding while the interpreter continues to run. This is on Windows (95, 98, 2000), under linux, the problem does not occur. All parameters passed have int-values, we checked that first. The exception can be caught via a try-statement, but Tk will stop responding anyway. ---snip self.rectangle =self.canvas.create_rectangle(self.x,self.y+1,self.x2,self.y 2-1) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1961, in create_rectangle return self._create('rectangle', args, kw) File "D:\PYTHON21\lib\lib-tk\Tkinter.py", line 1939, in _create (self._w, 'create', itemType) ValueError: invalid literal for int(): None ---snap ---------------------------------------------------------------------- >Comment By: T. Koehler (rasfahan) Date: 2002-10-23 18:29 Message: Logged In: YES user_id=634021 So far, I have failed to produce the bug in a small code-snippet. We use no library that isn't included in the standard python downloads, and the bug is reproducible with all 2.x versions. The create_rectangle call is located in another thread (created with thread.start_new_thread), though, than the Tk.mainloop of the root window of the canvas - might that be a problem? Unfortunatly, I do not have access to a debugger/c-compiler for windows, except for cygwin, where the problem does not exist. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 13:40 Message: Logged In: YES user_id=21627 As I said, this is difficult to understand, since _tkinter has no return Py_None in the relevant code: it might be memory corruption in an completely unrelated module. Are you using any funny extension modules? Can you post a self-contained example that might allow me to reproduce the problem? Could you try to debug the associated C code in a debugger? I.e. set a breakpoint onto the single return in Tkapp_Call (the USING_OBJECTS version), and conditionalize it on res==Py_None. Then inspect the state of the Tcl interp. Sorry I can't be of more help. ---------------------------------------------------------------------- Comment By: T. Koehler (rasfahan) Date: 2002-10-23 11:09 Message: Logged In: YES user_id=634021 Ok, here's the output of the last two print-statements before the exception from getint(). To me it looks as if the tk.app.call actually did return None. ('.8476780.13726076.8520076', 'create', 'rectangle', 50, 3, 250, \ 13, '-fill', '#00FF00') None ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-22 17:03 Message: Logged In: YES user_id=21627 Can you please investigate this a little bit further? Split the return statement in _create into several parts command = (self._w, 'create', itemType) + args + \ self._options(cnf, kw) print command result = apply(self.tk.call, command) print result return getint(result) It seems that result will become None. This, in turn, is quite impossible: tk.app.call will never return None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626936&group_id=5470 From noreply@sourceforge.net Wed Oct 23 23:52:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 15:52:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-627798 ] KeyPress bindings don't work Message-ID: Bugs item #627798, was opened at 2002-10-23 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627798&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Roman Khramets (reaux74) Assigned to: Nobody/Anonymous (nobody) Summary: KeyPress bindings don't work Initial Comment: Hi, I don't think keypress bindings work properly in Tkinter. When I bind "" to a method of a Frame-derived class, it does not work under Windows XP (not sure about other OSes). Here is a code snippet I am using. Please, see the file attached for the actual code. Thanks, ..Roman ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627798&group_id=5470 From noreply@sourceforge.net Wed Oct 23 23:53:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 15:53:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-627798 ] KeyPress bindings don't work Message-ID: Bugs item #627798, was opened at 2002-10-23 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627798&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Roman Khramets (reaux74) Assigned to: Nobody/Anonymous (nobody) Summary: KeyPress bindings don't work Initial Comment: Hi, I don't think keypress bindings work properly in Tkinter. When I bind "" to a method of a Frame-derived class, it does not work under Windows XP (not sure about other OSes). Here is a code snippet I am using. Please, see the file attached for the actual code. Thanks, ..Roman ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627798&group_id=5470 From noreply@sourceforge.net Thu Oct 24 00:20:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 16:20:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh Message-ID: Bugs item #626543, was opened at 2002-10-21 21:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't do HTTP-EQUIV & Refresh Initial Comment: I just added support for HTML's META HTTP-EQUIV and zero-time Refresh HTTP headers to my 'ClientCookie' package (which exports essentially a clone of the urllib2 interface that knows about cookies, making use of urllib2 in the implementation). I didn't make a patch for urllib2 itself but it would be easy to do so. I don't plan to do this immediately, but will eventually (assuming Jeremy thinks it's advisible) -- I just wanted to register this fact to prevent duplication of effort. [BTW, this version of ClientCookie isn't on my web page yet -- my motherboard just died.] I'm sure you know this already, but: HTTP-EQUIV is just a way of putting headers in the HEAD section of an HTML document; Refresh is a Netscape 1.1 header that indicates that a browser should redirect after a specified time. Refresh headers with zero time act like redirections. The net result of the code I just wrote is that if you urlopen a URL that points to an HTML document like this: you're automatically redirected to "http://acme.com/new_url.htm". Same thing happens if the Refresh is in the HTTP headers, because all the HTTP-EQUIV headers are treated like real HTTP headers. Refresh with non-zero delay time is ignored (the urlopen returns the document body unchanged and does not redirect, but does still add the Refresh header to the HTTP headers). A few issues: 0) AFAIK, the Refresh header is not specified in any RFC, but only here: http://wp.netscape.com/assist/net_sites/pushpull.html (HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe earlier ones too) 1) Infinite loops should be detected, as for HTTP 30x? Presumably yes. 2) Should add HTTP-EQUIV headers to response object, or just treat them like headers internally? Perhaps it should be possible to get both behaviours? 3) Bug in my implementation: is greedy with reading body data from httplib's file object. John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2002-10-24 00:20 Message: Logged In: YES user_id=261020 What do you think the solution to the backwards- compatibility problem is? Leave urllib2 as-is? Add a switch to turn it on? Something else? At the moment, I just deal with it in AbstractHTTPHandler. It would be nice to treat it like the other redirections, by writing a RefreshHandler -- this would solve the backwards- compatibility issue. However, OpenerDirector.error always calls http_error_xxx ATM (where xxx is the HTTP error code), so without changing that, I don't think a RefreshHandler is really possible. I suppose the sensible solution is just to make a new HTTPHandler and HTTPSHandler? Can you think of any way in which supporting HTTP-EQUIV would mess up backwards compatibility, assuming the body is unchanged but the headers do have the HTTP-EQUIV headers added? John ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-23 14:54 Message: Logged In: YES user_id=21627 In addition to the issues you have mentioned, there is also the backwards compatibility issue: Some applications might expect to get a meta-refresh document from urllib, then parse it and retry themselves. Those applications would break with such a change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 From noreply@sourceforge.net Thu Oct 24 02:16:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Oct 2002 18:16:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-627864 ] curses library not found during make Message-ID: Bugs item #627864, was opened at 2002-10-23 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 Category: Installation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Javier Streb (jstreb) Assigned to: Nobody/Anonymous (nobody) Summary: curses library not found during make Initial Comment: Hi, I'm compiling Python v. 2.2.2 on an RS/6000 running AIX v 4.3.3.75 using gnu.gcc version 2.95.3.0 as the compiler. In the configuration phase I had to specify "./configure --with-gcc" because it was telling me the "C compiler cannot create executables". gcc is the only compiler on the machine. During the "make" after a quite a lot of processing I get: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/wwwlogs/python/Python-2.2.2/./Include -I/usr/local/include -I/wwwlogs/python/Python-2.2.2/Include -I/wwwlogs/python/Python-2.2.2 -c /wwwlogs/python/Python-2.2.2/Modules/_cursesmodule.c -o build/temp.aix-4.3-2.2/_cursesmodule.o ./Modules/ld_so_aix gcc -bI:Modules/python.exp build/temp.aix-4.3-2.2/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-4.3-2.2/_curses.so collect2: Library libtermcap not found WARNING: removing "_curses" since importing it failed error: build/lib.aix-4.3-2.2/_curses.so: No such file or directory make: 1254-004 The error code from the last command is 1. I have /usr/include/curses.h in the system and will attempt to recompile using that library. Any pointers will be much appreciated ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 From noreply@sourceforge.net Thu Oct 24 21:52:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 13:52:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-628246 ] Set constructor fails with NameError Message-ID: Bugs item #628246, was opened at 2002-10-24 20:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: Set constructor fails with NameError Initial Comment: Here is a toy demo of the problem: def baditer(): raise TypeError yield 1 import sets sets.Set(baditer()) Traceback (most recent call last): File "/tmp/baditer.py", line 8, in ? sets.Set(baditer()) File "/usr/local/lib/python2.3/sets.py", line 367, in __init__ self._update(iterable) File "/usr/local/lib/python2.3/sets.py", line 330, in _update transform = getattr(element, "_as_immutable", None) UnboundLocalError: local variable 'element' referenced before assignment The _update() method has a try/except for TypeError that is trying to catch failures to place set elements in the dictionary. The try/except also wraps a for loop over an iterator. So if something goes wrong and the iterator raises TypeError, the failed-to-insert-element-in-dict code is run. The obvious solution, it seems, is to have the try/except inside the for loop so that it only catches errors in dict insertion. Tim points out that this would be slow. The example above is a toy, but I ran into this bug in a real application where debugging was made harded because the Set code was catching an exception when it shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628246&group_id=5470 From noreply@sourceforge.net Thu Oct 24 22:18:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 14:18:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-628258 ] pydoc.Helper.topics not based on docs Message-ID: Bugs item #628258, was opened at 2002-10-24 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628258&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: pydoc.Helper.topics not based on docs Initial Comment: The pydoc module includes a list of topics that map topic names used in the interactive help facility to the names of HTML files in the standard documentation. We need some facility to maintain this mapping as part of the documentation. This facility needs to be designed and implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=628258&group_id=5470 From noreply@sourceforge.net Thu Oct 24 22:15:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 14:15:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-624860 ] help(UNICODE) -- reference page missing Message-ID: Bugs item #624860, was opened at 2002-10-17 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624860&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: help(UNICODE) -- reference page missing Initial Comment: Entering IDLE in 2.2.2 on Win2K: >>> help() help> topics Lists (among many others), UNICODE. Howver, help> UNICODE elicits the error: could not read docs from C:\PYTHON22\doc/ref/unicode.html It seemed the only entry in topics that did fail, but I am not certain this is so. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-24 17:15 Message: Logged In: YES user_id=3066 I've looked into this briefly, and it looks like this is caused by the pydoc module (which implements the interactive help facility) having a static mapping of topic names to HTML files. Since this list is static in the code, and not generated from the documentation in any way, it's out of date. That section (which was available for Python 2.1.x) was never filled in with anything more than "XXX explain more here...". It's not at all clear what documentation this should point to; I suspect it's material that still needs to be written. I'll open a separate bug on the matter that the list of topics is not integrated with the documentation maintenance -- it should be so we're more aware of this mapping and don't break it accidentally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624860&group_id=5470 From noreply@sourceforge.net Thu Oct 24 21:56:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 13:56:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-577000 ] Wrong description for PyErr_Restore Message-ID: Bugs item #577000, was opened at 2002-07-03 10:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577000&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong description for PyErr_Restore Initial Comment: The description for PyErr_Restore() says: "The exception type should be a string or class; if it is a class, the value should be an instance of that class." This is apparently wrong, if you call PyErr_SetString() for example, the value is a string object, and the exception type is whatever has been passed to the call. I don't know the rules, so I cannot supply a patch. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-24 16:56 Message: Logged In: YES user_id=3066 Fixed in Doc/api/exceptions.tex 1.12 and 1.3.6.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=577000&group_id=5470 From noreply@sourceforge.net Thu Oct 24 22:42:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 14:42:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-619400 ] test_builtin hangs on MacOSX 10.2.1 Message-ID: Bugs item #619400, was opened at 2002-10-06 23:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619400&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_builtin hangs on MacOSX 10.2.1 Initial Comment: Test_builtin appears to hang on Mac OS X 10.2.1, in the 'list' section. Actually, if you are low on swapspace (or, equivalently, on freespace on your system drive) it may hang your whole system. Python cannot be interrupted (control-c) at this moment, but I'm sometimes able to control-z and kill. My guess right now is that 10.2.1 overcommits memory and that this somehow hangs Python. I have never seen this problem on 10.1.X or 10.2, but I will investigate. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-10-24 23:42 Message: Logged In: YES user_id=45365 Test_builtin contained a bug, the intention was to test malloc failure but the amount allocated was actually possible on Jaguar (and some other platforms). The test has been fixed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-07 08:29 Message: Logged In: YES user_id=21627 I think this is a duplicate of # 616019. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619400&group_id=5470 From noreply@sourceforge.net Thu Oct 24 23:02:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 15:02:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-619245 ] PythonLauncher Dialogs do not work Message-ID: Bugs item #619245, was opened at 2002-10-06 16:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 Category: Macintosh >Group: Not a Bug >Status: Closed Resolution: None Priority: 5 Submitted By: Bill Bedford (billbedford) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher Dialogs do not work Initial Comment: While converting some scripts to Python 2.3a using PythonLauncher, I find that if the script opens a dialog, the dialog can not receive mouse clicks. The only way to dismiss the dialog is the quit the Terminal. There is some functionality in the open file dialogs in that you can select a file, but none of the other controls work. Python 2.3a OS X 10.1.5 ---------------------------------------------------------------------- Comment By: Bill Bedford (billbedford) Date: 2002-10-08 11:27 Message: Logged In: YES user_id=624163 Jack You are right I misunderstood the pythonw thing. What I did was to change the application to open the file and double clicked on the icon. What I should also have done is to change the file extension to .pyw. When I do that the dialogs work as expected. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-10-06 23:59 Message: Logged In: YES user_id=45365 Bill, I think there's a misunderstanding here. Are you using PythonLauncher from the terminal? It isn't intended to be used as such, for that you should use "pythonw". If this is the problem let me know (it can probably be fixed, or PythonLauncher should complain). If it isn't what you're doing please give me a recipe to repeat this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619245&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:50:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:50:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-616211 ] packages doc in the tutorial Message-ID: Bugs item #616211, was opened at 2002-09-29 14:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616211&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Samuele Pedroni (pedronis) >Assigned to: Raymond Hettinger (rhettinger) Summary: packages doc in the tutorial Initial Comment: The packages section in the tutorial (6.4) could be more explicit about the fact that top-level packages are supposed to be direct subdirs of dirs on sys.path. It seems that is this not stated explicitly. The section seems to come straight from the packages' essay, which in the whole made that clear. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-24 15:50 Message: Logged In: YES user_id=3066 Raymond: I'd say the subdirectory is the package, not that it contains the package. If you can adjust the language for that, go ahead and check this in for r22-maint and the trunk, and close the report. Thanks! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-03 02:08 Message: Logged In: YES user_id=80475 Draft patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616211&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:52:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:52:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-627864 ] curses library not found during make Message-ID: Bugs item #627864, was opened at 2002-10-24 03:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 Category: Installation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Javier Streb (jstreb) Assigned to: Nobody/Anonymous (nobody) Summary: curses library not found during make Initial Comment: Hi, I'm compiling Python v. 2.2.2 on an RS/6000 running AIX v 4.3.3.75 using gnu.gcc version 2.95.3.0 as the compiler. In the configuration phase I had to specify "./configure --with-gcc" because it was telling me the "C compiler cannot create executables". gcc is the only compiler on the machine. During the "make" after a quite a lot of processing I get: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/wwwlogs/python/Python-2.2.2/./Include -I/usr/local/include -I/wwwlogs/python/Python-2.2.2/Include -I/wwwlogs/python/Python-2.2.2 -c /wwwlogs/python/Python-2.2.2/Modules/_cursesmodule.c -o build/temp.aix-4.3-2.2/_cursesmodule.o ./Modules/ld_so_aix gcc -bI:Modules/python.exp build/temp.aix-4.3-2.2/_cursesmodule.o -L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-4.3-2.2/_curses.so collect2: Library libtermcap not found WARNING: removing "_curses" since importing it failed error: build/lib.aix-4.3-2.2/_curses.so: No such file or directory make: 1254-004 The error code from the last command is 1. I have /usr/include/curses.h in the system and will attempt to recompile using that library. Any pointers will be much appreciated ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-10-24 21:52 Message: Logged In: YES user_id=21627 On the "C compiler not found": Can you please attach the config.log of a run that aborts with that message (and/or read it yourself and draw conclusions). On curses: It does not find libtermcap. The header file alone is insufficient; you need the library as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=627864&group_id=5470 From noreply@sourceforge.net Thu Oct 24 20:58:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 12:58:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-546579 ] Nested anchors in Ref Man index.html Message-ID: Bugs item #546579, was opened at 2002-04-20 16:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546579&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Nested anchors in Ref Man index.html Initial Comment: God only knows what Soureforge will do to this: """ This line from the 2.2 Doc/ref/index.html confuses prechm.py:
  • 2.1.6 Blank lines   Nested in general gives it trouble, and this one is particularly weird. """ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-24 15:58 Message: Logged In: YES user_id=3066 Fixed in Doc/ref/ref2.tex revisions 1.46 and 1.34.6.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546579&group_id=5470 From noreply@sourceforge.net Thu Oct 24 21:01:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 13:01:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-492619 ] __del__ docs need update Message-ID: Bugs item #492619, was opened at 2001-12-13 16:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __del__ docs need update Initial Comment: Similarly to words added in 2.2 to the gc module docs and extension docs, the Ref Man's section on __del__ should be clearer about the interactions between objects with __del__ methods and cyclic gc. The Ref Man should also be clearer about which parts of the semantics hold across all Python implementations, and which are specific to CPython (e.g., IIRC, __del__ isn't called by magic at all in Jython). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-24 16:01 Message: Logged In: YES user_id=3066 Looks like this was fixed a long time ago and just never closed. Closing this now. ---------------------------------------------------------------------- Comment By: Finn Bock (bckfnn) Date: 2001-12-15 10:36 Message: Logged In: YES user_id=4201 __del__ is only called once in Jython, even if the object is made reachable by the __del__ method. This restriction is inherited from java. A known difference which isn't covered by the ref, is that Jython requires that a class is born with a __del__ method in order to call it during finalization. Added a __del__ method to a class after the "class" statement does not enable the __del__ magic. I dunno if such implementation details should be documented. In general I think the describtion for __del__ also covers the gist of __del__ in Jython. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-14 17:53 Message: Logged In: YES user_id=3066 Fixed for CPython in Doc/ref/ref3.tex 1.82. Finn, can you review the __del__() description for Jython? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=492619&group_id=5470 From noreply@sourceforge.net Thu Oct 24 21:31:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Oct 2002 13:31:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-505150 ] mac module documentation inaccuracy. Message-ID: Bugs item #505150, was opened at 2002-01-17 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505150&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Fred L. Drake, Jr. (fdrake) 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. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-24 16:31 Message: Logged In: YES user_id=3066 Not sure why this is still open; it looks like the docs already have all the relevant updates. Closing the report. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-02-15 05:08 Message: Logged In: YES user_id=45365 You can't. After some discussion on the SIG this was deemed to not be important enough to stop us getting rid of xstat(), nobody on the list ever used the resource size. But you're right, it probably needs a note in the docs. Maybe add a line "This does not give you the resource fork size, but that information is of limited interest anyway". ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-02-14 11:49 Message: Logged In: YES user_id=3066 Jack -- the FSSpec object as documented allows access to the creator and type information, but not the size of the resource fork. How should the caller get that? Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-02-05 17:22 Message: Logged In: YES user_id=45365 Here is a patch for libmac.tex. I'll leave it to you to replace the \code{} sections with one of the gazillion macros I can never remember, hope you don't mind:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=505150&group_id=5470 From noreply@sourceforge.net Fri Oct 25 14:44:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 06:44:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas Message-ID: Bugs item #451547, was opened at 2001-08-16 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 3 Submitted By: Gordon B. McMillan (gmcm) Assigned to: Guido van Rossum (gvanrossum) Summary: pickle / cPickle can't load lambdas Initial Comment: pickle and cPickle will happily dump a lambda, but on load, both report: SystemError: Failed to import class from module __main__ Seen on Py 2.1 & 1.5.2 >>> f = lambda x: x in (1,2,3) >>> o = cPickle.dumps(f) >>> f2 = cPickle.loads(o) Traceback (most recent call last): File "", line 1, in ? SystemError: Failed to import class from module __main__ >>> o = pickle.dumps(f) >>> f2 = pickle.loads(o) Traceback (most recent call last): File "", line 1, in ? File "c:\python21\lib\pickle.py", line 951, in loads return Unpickler(file).load() File "c:\python21\lib\pickle.py", line 567, in load dispatch[key](self) File "c:\python21\lib\pickle.py", line 780, in load_global klass = self.find_class(module, name) File "c:\python21\lib\pickle.py", line 790, in find_class raise SystemError, \ SystemError: Failed to import class from module __main__ ---------------------------------------------------------------------- Comment By: Dave Cole (davecole) Date: 2002-10-25 13:44 Message: Logged In: YES user_id=28658 I seem to be suffering from some unintentional consequences of this fix. I do not think that the pickle should fail in the follwing case. Wouldn't it be a better idea to just check for a successful of the pickled class instead of requiring the imported class to be stored at the same memory location? >>> import pickle, copy >>> o = copy._EmptyClass() >>> reload(copy) >>> pickle.dumps(o, 1) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/pickle.py", line 978, in dumps Pickler(file, bin).dump(object) File "/usr/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/usr/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/lib/python2.2/pickle.py", line 477, in save_inst save(cls) File "/usr/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/lib/python2.2/pickle.py", line 524, in save_global raise PicklingError( pickle.PicklingError: Can't pickle : it's not the same object as copy._EmptyClass ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-18 21:23 Message: Logged In: YES user_id=6380 I applied Gordon's patch, so this can be closed now. ---------------------------------------------------------------------- Comment By: Gordon B. McMillan (gmcm) Date: 2001-08-17 21:45 Message: Logged In: YES user_id=4923 Patch # 452239 is my attempt to patch cPickle.c to match Guido's patch to pickle.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-17 18:51 Message: Logged In: YES user_id=6380 I figured it out. In save_global(), I now try to import the module and then extract the name from the module; this must give us the same object. If it doesn't, raise PicklingError. Checked in as pickle.py rev 1.50. I can't close this yet because cPickle needs a similar patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 16:31 Message: Logged In: YES user_id=6380 I guess what you're missing is that pickling a function doesn't pickle the bytecode! It pickles the name instead. So a reference to "foo.bar" is pickled as "foo.bar", and the unpickler imports bar from foo. ---------------------------------------------------------------------- Comment By: Gordon B. McMillan (gmcm) Date: 2001-08-16 16:03 Message: Logged In: YES user_id=4923 Hmm. In the (simplistic) case I was trying, I can't see any significant difference between the lambda and the equivalent function (names differ, and the func has 2 appended & apparently unreachable bytecodes, but otherwise the func_* and func_code.co_* attributes match). So what am I missing? Lowering priority - I can live without it easily enough. But if lambda's won't load, they probably shouldn't dump. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-16 15:11 Message: Logged In: YES user_id=6380 I think I'll have to close this with a won't fix, or "then don't do that" resolution. The problem is that whenever a function or class is pickled, pickle must accept on blind faith that it can also be unpickled. How would you check that this is indeed the case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470 From noreply@sourceforge.net Fri Oct 25 20:48:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 12:48:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-621057 ] File write examples are inadequate Message-ID: Bugs item #621057, was opened at 2002-10-09 16:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Stagg (kandrew) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: File write examples are inadequate Initial Comment: The examples provided for writing to files in section 7.2 of the documentation are overly simple showing only writing of a static string. Reading through 7.1 (although not actually discussing file I/O) helps a little as the % operator is mentioned but the "...C sprintf()-style format string..." specifiers which are valid aren't cross referenced (and the 'Library Reference' is a largish search area). I had to find out experimentally that %f isn't valid although %d is. To date, I haven't been able to experimentally findout how to print a list or tuple. trying: file.write('"%s"', str(relatedMeasurements)) results in: TypeError: read-only buffer, tuple The addition of examples printing a list or tuple would be extremely helpful. Similarly, examples of using file.write() to produce print type output would be very illuminating. ---------------------------------------------------------------------- >Comment By: Andrew Stagg (kandrew) Date: 2002-10-25 13:48 Message: Logged In: YES user_id=577467 The comment that the example is incomplete is well founded. Therefore I attach a standalone example of the problem I ran into: >>> peakPres = {'Unknown':0} >>> peakPres['meas1'] = 0 >>> peakPres['meas1'] = peakPres['meas1']+1 >>> print peakPres {'meas1': 1, 'Unknown': 0} >>> for pres in peakPres.keys(): ... print pres, peakPres[pres] ... meas1 1 Unknown 0 >>> file.open('test1.dat', 'w') Traceback (innermost last): File "", line 1, in ? NameError: file >>> file = open('test1.dat', 'w') >>> for pres in peakPres.keys(): ... file.write('%s: %s, ', pres, peakPres[pres]) ... Traceback (innermost last): File "", line 2, in ? TypeError: read-only buffer, tuple >>> Note that the call to print works while the call to file.write does not. The reason is that the print statement makes a call to __str__. Thus, and file.write() do not have the same relationship as C++ stream classes ostream and ofstream or C's printf and fprintf. (As implied by rhettinger and the current contents of the tutorial.) Hence, my request that the tutorial's examples of file output be expanded to the non-trival level of writing list and dictionary members. Cross referenceing the legal format specifiers (in the language reference) from the tutorial examples would also be extremely helpful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-23 07:58 Message: Logged In: YES user_id=80475 Here are a few thoughts: The % formatting operator is fully documented in 2.2.6.2 of the library reference. I think the tutorial should be kept at an introductory level and the details left in the reference. OTOH, I agree that 2.2.6.2 is hard to find. %f is a valid format: '%f' % 3.14 There are several oddities in the file.write error in your post. First, the double quotes inside the single quotes (perhaps this is intentional). Second, the comma should have been the % formatting operator. Third, since 'file' is the name of a type, it is normally a good idea to pick another name like 'infil' or 'outfil'. The post doesn't include enough information to be able to reproduce the error. We need to know the value of relatedMeasurements and have a line showing how the file was opened. To debug the example, it would help to separate the concerns of file writing from the string formatting. Get the program to successfully format and print a string. Only then, add a line to write it out to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 From noreply@sourceforge.net Fri Oct 25 20:50:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 12:50:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-621057 ] File write examples are inadequate Message-ID: Bugs item #621057, was opened at 2002-10-09 16:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Stagg (kandrew) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: File write examples are inadequate Initial Comment: The examples provided for writing to files in section 7.2 of the documentation are overly simple showing only writing of a static string. Reading through 7.1 (although not actually discussing file I/O) helps a little as the % operator is mentioned but the "...C sprintf()-style format string..." specifiers which are valid aren't cross referenced (and the 'Library Reference' is a largish search area). I had to find out experimentally that %f isn't valid although %d is. To date, I haven't been able to experimentally findout how to print a list or tuple. trying: file.write('"%s"', str(relatedMeasurements)) results in: TypeError: read-only buffer, tuple The addition of examples printing a list or tuple would be extremely helpful. Similarly, examples of using file.write() to produce print type output would be very illuminating. ---------------------------------------------------------------------- >Comment By: Andrew Stagg (kandrew) Date: 2002-10-25 13:50 Message: Logged In: YES user_id=577467 The comment that the example is incomplete is well founded. Therefore I attach a standalone example of the problem I ran into: >>> peakPres = {'Unknown':0} >>> peakPres['meas1'] = 0 >>> peakPres['meas1'] = peakPres['meas1']+1 >>> print peakPres {'meas1': 1, 'Unknown': 0} >>> for pres in peakPres.keys(): ... print pres, peakPres[pres] ... meas1 1 Unknown 0 >>> file.open('test1.dat', 'w') Traceback (innermost last): File "", line 1, in ? NameError: file >>> file = open('test1.dat', 'w') >>> for pres in peakPres.keys(): ... file.write('%s: %s, ', pres, peakPres[pres]) ... Traceback (innermost last): File "", line 2, in ? TypeError: read-only buffer, tuple >>> Note that the call to print works while the call to file.write does not. The reason is that the print statement makes a call to __str__. Thus, and file.write() do not have the same relationship as C++ stream classes ostream and ofstream or C's printf and fprintf. (As implied by rhettinger and the current contents of the tutorial.) Hence, my request that the tutorial's examples of file output be expanded to the non-trival level of writing list and dictionary members. Cross referenceing the legal format specifiers (in the language reference) from the tutorial examples would also be extremely helpful. ---------------------------------------------------------------------- Comment By: Andrew Stagg (kandrew) Date: 2002-10-25 13:48 Message: Logged In: YES user_id=577467 The comment that the example is incomplete is well founded. Therefore I attach a standalone example of the problem I ran into: >>> peakPres = {'Unknown':0} >>> peakPres['meas1'] = 0 >>> peakPres['meas1'] = peakPres['meas1']+1 >>> print peakPres {'meas1': 1, 'Unknown': 0} >>> for pres in peakPres.keys(): ... print pres, peakPres[pres] ... meas1 1 Unknown 0 >>> file.open('test1.dat', 'w') Traceback (innermost last): File "", line 1, in ? NameError: file >>> file = open('test1.dat', 'w') >>> for pres in peakPres.keys(): ... file.write('%s: %s, ', pres, peakPres[pres]) ... Traceback (innermost last): File "", line 2, in ? TypeError: read-only buffer, tuple >>> Note that the call to print works while the call to file.write does not. The reason is that the print statement makes a call to __str__. Thus, and file.write() do not have the same relationship as C++ stream classes ostream and ofstream or C's printf and fprintf. (As implied by rhettinger and the current contents of the tutorial.) Hence, my request that the tutorial's examples of file output be expanded to the non-trival level of writing list and dictionary members. Cross referenceing the legal format specifiers (in the language reference) from the tutorial examples would also be extremely helpful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-10-23 07:58 Message: Logged In: YES user_id=80475 Here are a few thoughts: The % formatting operator is fully documented in 2.2.6.2 of the library reference. I think the tutorial should be kept at an introductory level and the details left in the reference. OTOH, I agree that 2.2.6.2 is hard to find. %f is a valid format: '%f' % 3.14 There are several oddities in the file.write error in your post. First, the double quotes inside the single quotes (perhaps this is intentional). Second, the comma should have been the % formatting operator. Third, since 'file' is the name of a type, it is normally a good idea to pick another name like 'infil' or 'outfil'. The post doesn't include enough information to be able to reproduce the error. We need to know the value of relatedMeasurements and have a line showing how the file was opened. To debug the example, it would help to separate the concerns of file writing from the string formatting. Get the program to successfully format and print a string. Only then, add a line to write it out to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470 From noreply@sourceforge.net Fri Oct 25 21:44:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Oct 2002 13:44:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser cleanup, items() [needs tests] Message-ID: Bugs item #545096, was opened at 2002-04-17 06:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser cleanup, items() [needs tests] Initial Comment: The first patch fixes a bug, implements some speed improvements, some memory consumption improvements, enforces the usage of the already available global variables, and extends the allowed chars in option names to be very permissive. The second one, if used, is supposed to be applied over the first one, and implements a walk() generator method for walking trough the options of a section. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-10-25 16:44 Message: Logged In: YES user_id=3066 Added tests of .items() in Lib/test/test_cfgparser.py revision 1.17. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-27 11:50 Message: Logged In: YES user_id=3066 Added code cleanup and bugfix code in Lib/ConfigParser.py revisions 1.45 and 1.38.10.3. The new items() method was checked in as Lib/ConfigParser.py 1.46 and Doc/lib/libcfgparser.tex 1.23. I still need to write unit tests for this method, so this tracker item will remain open for now. Updated summary. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-07-03 15:45 Message: Logged In: YES user_id=7887 No problems at all!! Thank you! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-03 00:08 Message: Logged In: YES user_id=3066 Any objections to my renaming "walk" to "items" (or even "section_items")? "walk" makes me think of os.path.walk(), which uses a callback; what the function returns is a list of name-value pairs, though, which makes me think "items". Other than this, I'm ready to commit. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-22 00:09 Message: Logged In: YES user_id=7887 Deal!! ;-) Here is the updated patch. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 22:16 Message: Logged In: YES user_id=3066 Thanks! I can take care of the referred bug; I already know how I want to solve that one. Thanks! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-21 22:14 Message: Logged In: YES user_id=7887 Thanks for your review Fred! I'll fix the patch as suggested, and work on a solution for the referred bug as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 21:38 Message: Logged In: YES user_id=3066 Changed to a "bug" report even though it's a patch, so that all the ConfigParser reports can show up together. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 13:22 Message: Logged In: YES user_id=3066 I'd like to accept a variation on this patch. Specifically, I'd like "section in self.sections()" tests to become "sections in self.__sections" consistently; your proposed patch is better than the original, but as long as we're not supporting subclassing in this way, let's go ahead and use the better-performing solution. I'll accept the use of MAX_INTERPOLATION_DEPTH and your changes to the interpolation loop, but the loop itself will probably be re-written later, in response to SF bug #511737. The walk() method will need documentation. Can you prepare a new patch for this? Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-21 12:20 Message: Logged In: YES user_id=3066 Ken appears non-responsive, re-assigning to me. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-06-12 21:42 Message: Logged In: YES user_id=3066 Ken, can you recall our thinking on the use of the constant for MAX_INTERPOLATION_DEPTH when this was first written? I think you were more involved in this than the rest of us at the time. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-06-03 17:45 Message: Logged In: YES user_id=7887 Hello Fred! - About has_section(), I thought about the possibility of subclassing it. But, besides agreeing with you on the messy code matter, other functions weren't (and still aren't) considering this possibility, so I doubt some one will be able to subclass it anyways. Anyway, I may change the patch to use whatever you suggest. - About MAX_INTERPOLATION_DEPTH, I understand your position of wanting "a safety net", but my intention of using it in the code was not to let the user change it, but to clarify and give consistence to the code. I think using literal constants in the code is not a good measure at all. If this was adopted, many modules would have to be changed (in a bad way) for consistence. With a quick look at the library, I was able to find smtpd.py, base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose constants. You'll probably agree with me if you think about this more extensively. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 12:11 Message: Logged In: YES user_id=3066 I should clarify: By "retain the use of the constant" I mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 12:06 Message: Logged In: YES user_id=3066 Two comments: - "section in self.__sections.keys()" can be written (still more efficiently) as "section in self.__sections", *but* the use of the sections() method is done to be subclass-friendly. I'm not sure how important this is since I can't imagine anyone actually subclassing from such a mass of messy code. Perhaps these could be modified to use the has_section() method, which is relatively new. - MAX_INTERPOLATION_DEPTH was not "honored" in the code since it's really a safety net; there's no intention that client code be able to change it. (The sanity of the value is not checked before use.) I'm inclined to retain the use of the constant in the interpolation code, and add a comment above the constant the it exists for informational purposes only. Otherwise, I'm fine with the patch. ;-) Sorry for the delay in responding to this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 13:55 Message: Logged In: YES user_id=6380 I'm assigning this to Fred Drake, who has some opinions on ConfigParser. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-04-18 13:07 Message: Logged In: YES user_id=7887 I'd rather explain here the patch that changes behavior, since it's pretty small. This line in the regular expression OPTCRE: r'(?P