From noreply@sourceforge.net Sun Dec 1 01:55:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Nov 2002 17:55:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 8 Submitted By: Marius Gedminas (mgedmin) >Assigned to: Martin v. Löwis (loewis) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 01:55 Message: Logged In: YES user_id=7887 Thanks for noticing that Martin. Here is a new revision, with suggested documentation changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-28 11:00 Message: Logged In: YES user_id=21627 I'm still missing proposed documentation changes. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-27 15:58 Message: Logged In: YES user_id=7887 I'm attaching a new revised patch. I'll also increase the priority, to reflect the serious problems this bug could cause. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 16:18 Message: Logged In: YES user_id=7887 You're right about EAGAIN. The behavior I mentioned seems to be valid only for old Unixes, as presented here: http://www.gnu.org/manual/glibc/html_mono/libc.html So indeed we should check for both. OTOH, the above URL also mentions that EAGAIN can happen in blocking situations as well: "On some systems, reading a large amount of data from a character special file can also fail with EAGAIN if the kernel cannot find enough physical memory to lock down the user's pages." Also, the statement in the documentation you mention isn't true even without my patch. We currently check for "readbytes < requestedbytes" and break the loop if it happens. Indeed, that's one of the reasons that created the second problem I've mentioned. Enforcing this behavior, I could see that mentioned in the URL above: "Any condition that could result in EAGAIN can instead result in a successful read which returns fewer bytes than requested. Calling read again immediately would result in EAGAIN." Thusly, applying this patch we wouldn't be introducing a new behavior, but just enforcing a single behavior in every case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 14:18 Message: Logged In: YES user_id=21627 Depends on what system you have. On Linux-i386, we have #define EWOULDBLOCK EAGAIN so it is necessarily the same thing. Can you report on what system EAGAIN happens even if the file descriptor is non-blocking? As for documentation changes: The documentation currently says Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes) I believe this statement is no longer true: with your changes, it will return less data even without hitting EOF. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 13:50 Message: Logged In: YES user_id=7887 Martin, EAGAIN is not the same as EWOULDBLOCK. While EWOULDBLOCK will only be issued in a situation where the filedescriptor is marked as non-blocking, EAGAIN can happen at any time, including when requestsize == -1 (read everything from the fd). If we're going to handle EAGAIN, we must ensure that the loop is not broken when it happens, instead of using the same solution proposed for EWOULDBLOCK. Do you think we should do that as well? You're right about EWOULDBLOCK not being available. I'll include the required #ifdef, and also the suggested comment. Could you please clarify what you mean in this sentence: "In any case, please update the documentation to describe the special cases that you add.". IMO, the proposed patch is not adding special cases. It's just fixing the algorithm to behave the same way in all situations. In that case, what doucmentation should be updated, in your opinion? Or perhaps you're talking about the proposed e.data solution, which would be used in other cases like EINTR similars? Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 08:29 Message: Logged In: YES user_id=21627 I think the processing of the error condition is wrong, in a number of ways: - Posix allows for both EAGAIN and EWOULDBLOCK to be signalled in this case. - Neither EAGAIN nor EWOULDBLOCK are guaranteed to exist on all systems. - Please add a comment to the break; to indicate what the purpose of this code is. Also, I think there are a number of other cases where bytesread might be non-zero, e.g. if EINTR was signalled. It's not clear what the best solution would be, I propose that the exception carries an attribute "data" to denote the short data. Of course, in the EINTR case, the original exception is lost and a KeyboardInterrupt is raised instead, so putting the data into the exception might be pointless... In any case, please update the documentation to describe the special cases that you add. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 16:43 Message: Logged In: YES user_id=7887 Martin, could you please review that? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=7887 Great catch Marius! Thank you very much! I could identify the following problems from your report: - If (requestsize == -1) and after a few iterations, fread() signals EWOULDBLOCK with (chunksize == 0), all read data is lost because an exception is raised. - When (chunksize != 0) and EWOULDBLOCK is signaled, ferror() will be flagged. Then the next iteration will fail if: 1) read data has length 0 because EWOULDBLOCK is signaled again but errno is still set to 0 (I don't know why errno is not reset in that case); 2) read data has length 0 because a block with the exact requested size is read. The attached tests show these problems. The first problem is a little bit harder to trigger. I had to preset SMALLCHUNK to 4096 in fileobject.c, because my Linux refused to return a chunk greater than that from fread(). The second problem should be visible without further tweakings. I have also attached a solution to the problem. This solution works because: - If (chunksize == 0), (errno == EWOULDBLOCK) and (readbytes > 0), there's no point in raising an exception, as we got some data for the user, just like when (bytesread < buffersize). - When (chunksize != 0) and EWOULDBLOCK is signaled, it's not considered an error. OTOH, ferror() is still being set. clearerr() should be called in the stream before breaking the loop. - If (bytesread == buffersize) and (bytesrequest >= 0), it means that we already got all the requested data, and thus there's no point in trying to read more data from the file and forcing (chunksize == 0) without ferror() being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Sun Dec 1 02:05:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Nov 2002 18:05:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-448679 ] Left to right Message-ID: Bugs item #448679, was opened at 2001-08-07 06:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Martin v. Löwis (loewis) Summary: Left to right Initial Comment: The Ref Man doesn't explicitly say anything about Python's left-to-right evaluation order. Strict left- to-right was Guido's intent, though, and it comes up a few times per year on c.l.py (indeed, I was just replying to a msg asking about it). The docs should get fleshed out. There's also a bug: >>> counter = 0 >>> def i(): ... global counter ... counter += 1 ... return counter ... >>> {i(): i()} {2: 1} >>> {i(): i(), i(): i()} {4: 3, 6: 5} >>> That is, key:value *pairs* are evaluated left to right, but within a single key:value pair, the value gets evaluated first. When I asked Guido about that some years ago, he agreed it was a bug. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 02:05 Message: Logged In: YES user_id=7887 Martin, could you please review the proposed solution? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-26 22:56 Message: Logged In: YES user_id=7887 I'm attaching a suggested solution for the problem, including documentation and reordering of dict evaluation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 09:58 Message: Logged In: YES user_id=21627 With the patch attached, this behaviour is cast into stone (or, atleast into a SF tracker :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470 From noreply@sourceforge.net Sun Dec 1 02:07:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 30 Nov 2002 18:07:36 -0800 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 23: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: christian soldan (elacademico) Date: 2002-11-30 23:07 Message: Logged In: YES user_id=659858 how do i hack my fuckers friends ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-30 20:23 Message: Logged In: NO i would like to know some moves ---------------------------------------------------------------------- Comment By: John Popplewell (johnnypops) Date: 2002-08-21 21: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 20: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 18: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 18: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 15: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 14: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 11: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 11: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 10: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 10: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 09: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 22:00 Message: Logged In: YES user_id=6380 AFAIK we never distributed a threaded build. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2002-08-14 21: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 16: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 15: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 14: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 10: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 16: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 15: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 13: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 10: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-23 00: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 23: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 22: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 21: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 20: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 20: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 19: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 19: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 05: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 14: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 17: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-06 02: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 23: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 17: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 13: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 11:40 Message: Back to Tim since I have no clue what to do here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-12 14: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 04: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 Sun Dec 1 09:09:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 01:09:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-645843 ] findall returns '' instead of None Message-ID: Bugs item #645843, was opened at 2002-11-29 22:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645843&group_id=5470 Category: Regular Expressions Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Fredrik Lundh (effbot) Summary: findall returns '' instead of None Initial Comment: Dear Pythonistas: Thank you for Python! >>> import re >>> re.match("(B+)(A+)?", "B").groups() # test 1 ('B', None) >>> re.match("(B+)(A*)", "B").groups() # test 2 ('B', '') >>> re.findall("(B+)(A+)?", "B") # test 3 [('B', '')] >>> re.findall("(B+)(A*)", "B") # test 4 [('B', '')] I was expecting test 3 to return [('B', None)], so this was a surprise to me. I also think that this behavior would be better, so that the results from test 3 and test 4 can be distinguished. (It doesn't matter in this test, but it could if there is a '|' disjunction, and I want to use "is None" to determine which side matched.) If you don't want to change the semantics, perhaps for compatibility reasons, or because you prefer these ones, then I suggest updating the doc of "findall" to mention this behavior. Regards, Zooko ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 10:09 Message: Logged In: YES user_id=38376 "pre" (Python 1.5.2's regular expression engine) is the reference for all semantic issues, and it does the same thing. Fred, can you add a brief note to the findall documentation (when findall returns tuples, it uses "" for both empty and non-existent matches) Zooko, if you really want the code to be changed, I suggest raising the issue on python-dev; we can always turn this bug report into a feature request later on. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-30 22:22 Message: Logged In: YES user_id=80475 Yes, test #3 looks like a bug to me. (A+) should not even be an empty match. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645843&group_id=5470 From noreply@sourceforge.net Sun Dec 1 11:20:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 03:20:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-645843 ] findall returns '' instead of None Message-ID: Bugs item #645843, was opened at 2002-11-29 22:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645843&group_id=5470 Category: Regular Expressions Group: Python 2.2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Fredrik Lundh (effbot) Summary: findall returns '' instead of None Initial Comment: Dear Pythonistas: Thank you for Python! >>> import re >>> re.match("(B+)(A+)?", "B").groups() # test 1 ('B', None) >>> re.match("(B+)(A*)", "B").groups() # test 2 ('B', '') >>> re.findall("(B+)(A+)?", "B") # test 3 [('B', '')] >>> re.findall("(B+)(A*)", "B") # test 4 [('B', '')] I was expecting test 3 to return [('B', None)], so this was a surprise to me. I also think that this behavior would be better, so that the results from test 3 and test 4 can be distinguished. (It doesn't matter in this test, but it could if there is a '|' disjunction, and I want to use "is None" to determine which side matched.) If you don't want to change the semantics, perhaps for compatibility reasons, or because you prefer these ones, then I suggest updating the doc of "findall" to mention this behavior. Regards, Zooko ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 12:20 Message: Logged In: YES user_id=38376 (footnote: to get a real match object, use finditer) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 10:09 Message: Logged In: YES user_id=38376 "pre" (Python 1.5.2's regular expression engine) is the reference for all semantic issues, and it does the same thing. Fred, can you add a brief note to the findall documentation (when findall returns tuples, it uses "" for both empty and non-existent matches) Zooko, if you really want the code to be changed, I suggest raising the issue on python-dev; we can always turn this bug report into a feature request later on. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-30 22:22 Message: Logged In: YES user_id=80475 Yes, test #3 looks like a bug to me. (A+) should not even be an empty match. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645843&group_id=5470 From noreply@sourceforge.net Sun Dec 1 11:21:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 03:21:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-645843 ] findall returns '' instead of None Message-ID: Bugs item #645843, was opened at 2002-11-29 22:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645843&group_id=5470 >Category: Documentation Group: Python 2.2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: findall returns '' instead of None Initial Comment: Dear Pythonistas: Thank you for Python! >>> import re >>> re.match("(B+)(A+)?", "B").groups() # test 1 ('B', None) >>> re.match("(B+)(A*)", "B").groups() # test 2 ('B', '') >>> re.findall("(B+)(A+)?", "B") # test 3 [('B', '')] >>> re.findall("(B+)(A*)", "B") # test 4 [('B', '')] I was expecting test 3 to return [('B', None)], so this was a surprise to me. I also think that this behavior would be better, so that the results from test 3 and test 4 can be distinguished. (It doesn't matter in this test, but it could if there is a '|' disjunction, and I want to use "is None" to determine which side matched.) If you don't want to change the semantics, perhaps for compatibility reasons, or because you prefer these ones, then I suggest updating the doc of "findall" to mention this behavior. Regards, Zooko ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 12:21 Message: Logged In: YES user_id=38376 (forgot to reassign to Fred; for more info, see followups) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 12:20 Message: Logged In: YES user_id=38376 (footnote: to get a real match object, use finditer) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 10:09 Message: Logged In: YES user_id=38376 "pre" (Python 1.5.2's regular expression engine) is the reference for all semantic issues, and it does the same thing. Fred, can you add a brief note to the findall documentation (when findall returns tuples, it uses "" for both empty and non-existent matches) Zooko, if you really want the code to be changed, I suggest raising the issue on python-dev; we can always turn this bug report into a feature request later on. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-11-30 22:22 Message: Logged In: YES user_id=80475 Yes, test #3 looks like a bug to me. (A+) should not even be an empty match. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645843&group_id=5470 From noreply@sourceforge.net Sun Dec 1 12:54:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 04:54:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-646408 ] old UnicodeData.txt Message-ID: Bugs item #646408, was opened at 2002-12-01 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: old UnicodeData.txt Initial Comment: [submitted at http://bugs.debian.org/171061] The version mentioned is CVS 021121 HEAD unicodedata.so is obviously built with older UnicodeData.txt file, and does not match new characters introduced in Unicode 3.2. To fix it, I copied UnicodeData.txt (conveniently provided by perl-modules in /usr/share/perl/5.8.0/unicore/UnicodeData.txt) to the top of unpacked python2.3 source package, renamed it to UnicodeData-Latest.txt, ran "python Tools/unicode/makeunicodedata.py" and then recompiled python2.3 package. This should probably be addressed upstream as well. before: >>> import unicodedata >>> unicodedata.name(u'\u20b0') Traceback (most recent call last): File "", line 1, in ? ValueError: no such name after: >>> import unicodedata >>> unicodedata.name(u'\u20b0') 'GERMAN PENNY SIGN' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 From noreply@sourceforge.net Sun Dec 1 13:18:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 05:18:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-646408 ] old UnicodeData.txt Message-ID: Bugs item #646408, was opened at 2002-12-01 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: old UnicodeData.txt Initial Comment: [submitted at http://bugs.debian.org/171061] The version mentioned is CVS 021121 HEAD unicodedata.so is obviously built with older UnicodeData.txt file, and does not match new characters introduced in Unicode 3.2. To fix it, I copied UnicodeData.txt (conveniently provided by perl-modules in /usr/share/perl/5.8.0/unicore/UnicodeData.txt) to the top of unpacked python2.3 source package, renamed it to UnicodeData-Latest.txt, ran "python Tools/unicode/makeunicodedata.py" and then recompiled python2.3 package. This should probably be addressed upstream as well. before: >>> import unicodedata >>> unicodedata.name(u'\u20b0') Traceback (most recent call last): File "", line 1, in ? ValueError: no such name after: >>> import unicodedata >>> unicodedata.name(u'\u20b0') 'GERMAN PENNY SIGN' ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 14:18 Message: Logged In: YES user_id=38376 Why is Debian shipping a "python2.3", when Python 2.3 hasn't been released yet (it's not even in alpha)? (the Unicode database in the current Python CVS has already been updated...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 From noreply@sourceforge.net Sun Dec 1 13:23:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 05:23:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 14:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Accepted Priority: 8 Submitted By: Marius Gedminas (mgedmin) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 14:23 Message: Logged In: YES user_id=21627 The patch looks good. Please apply it. If we can both agree that this is a bug fix (as it arranges to return data which were previously silently lost), I suggest to backport the patch also to the 2.2 tree (no further review needed). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 02:55 Message: Logged In: YES user_id=7887 Thanks for noticing that Martin. Here is a new revision, with suggested documentation changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-28 12:00 Message: Logged In: YES user_id=21627 I'm still missing proposed documentation changes. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-27 16:58 Message: Logged In: YES user_id=7887 I'm attaching a new revised patch. I'll also increase the priority, to reflect the serious problems this bug could cause. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 17:18 Message: Logged In: YES user_id=7887 You're right about EAGAIN. The behavior I mentioned seems to be valid only for old Unixes, as presented here: http://www.gnu.org/manual/glibc/html_mono/libc.html So indeed we should check for both. OTOH, the above URL also mentions that EAGAIN can happen in blocking situations as well: "On some systems, reading a large amount of data from a character special file can also fail with EAGAIN if the kernel cannot find enough physical memory to lock down the user's pages." Also, the statement in the documentation you mention isn't true even without my patch. We currently check for "readbytes < requestedbytes" and break the loop if it happens. Indeed, that's one of the reasons that created the second problem I've mentioned. Enforcing this behavior, I could see that mentioned in the URL above: "Any condition that could result in EAGAIN can instead result in a successful read which returns fewer bytes than requested. Calling read again immediately would result in EAGAIN." Thusly, applying this patch we wouldn't be introducing a new behavior, but just enforcing a single behavior in every case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 15:18 Message: Logged In: YES user_id=21627 Depends on what system you have. On Linux-i386, we have #define EWOULDBLOCK EAGAIN so it is necessarily the same thing. Can you report on what system EAGAIN happens even if the file descriptor is non-blocking? As for documentation changes: The documentation currently says Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes) I believe this statement is no longer true: with your changes, it will return less data even without hitting EOF. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 14:50 Message: Logged In: YES user_id=7887 Martin, EAGAIN is not the same as EWOULDBLOCK. While EWOULDBLOCK will only be issued in a situation where the filedescriptor is marked as non-blocking, EAGAIN can happen at any time, including when requestsize == -1 (read everything from the fd). If we're going to handle EAGAIN, we must ensure that the loop is not broken when it happens, instead of using the same solution proposed for EWOULDBLOCK. Do you think we should do that as well? You're right about EWOULDBLOCK not being available. I'll include the required #ifdef, and also the suggested comment. Could you please clarify what you mean in this sentence: "In any case, please update the documentation to describe the special cases that you add.". IMO, the proposed patch is not adding special cases. It's just fixing the algorithm to behave the same way in all situations. In that case, what doucmentation should be updated, in your opinion? Or perhaps you're talking about the proposed e.data solution, which would be used in other cases like EINTR similars? Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 09:29 Message: Logged In: YES user_id=21627 I think the processing of the error condition is wrong, in a number of ways: - Posix allows for both EAGAIN and EWOULDBLOCK to be signalled in this case. - Neither EAGAIN nor EWOULDBLOCK are guaranteed to exist on all systems. - Please add a comment to the break; to indicate what the purpose of this code is. Also, I think there are a number of other cases where bytesread might be non-zero, e.g. if EINTR was signalled. It's not clear what the best solution would be, I propose that the exception carries an attribute "data" to denote the short data. Of course, in the EINTR case, the original exception is lost and a KeyboardInterrupt is raised instead, so putting the data into the exception might be pointless... In any case, please update the documentation to describe the special cases that you add. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 17:43 Message: Logged In: YES user_id=7887 Martin, could you please review that? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 16:58 Message: Logged In: YES user_id=7887 Great catch Marius! Thank you very much! I could identify the following problems from your report: - If (requestsize == -1) and after a few iterations, fread() signals EWOULDBLOCK with (chunksize == 0), all read data is lost because an exception is raised. - When (chunksize != 0) and EWOULDBLOCK is signaled, ferror() will be flagged. Then the next iteration will fail if: 1) read data has length 0 because EWOULDBLOCK is signaled again but errno is still set to 0 (I don't know why errno is not reset in that case); 2) read data has length 0 because a block with the exact requested size is read. The attached tests show these problems. The first problem is a little bit harder to trigger. I had to preset SMALLCHUNK to 4096 in fileobject.c, because my Linux refused to return a chunk greater than that from fread(). The second problem should be visible without further tweakings. I have also attached a solution to the problem. This solution works because: - If (chunksize == 0), (errno == EWOULDBLOCK) and (readbytes > 0), there's no point in raising an exception, as we got some data for the user, just like when (bytesread < buffersize). - When (chunksize != 0) and EWOULDBLOCK is signaled, it's not considered an error. OTOH, ferror() is still being set. clearerr() should be called in the stream before breaking the loop. - If (bytesread == buffersize) and (bytesrequest >= 0), it means that we already got all the requested data, and thus there's no point in trying to read more data from the file and forcing (chunksize == 0) without ferror() being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Sun Dec 1 13:30:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 05:30:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-646408 ] old UnicodeData.txt Message-ID: Bugs item #646408, was opened at 2002-12-01 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: old UnicodeData.txt Initial Comment: [submitted at http://bugs.debian.org/171061] The version mentioned is CVS 021121 HEAD unicodedata.so is obviously built with older UnicodeData.txt file, and does not match new characters introduced in Unicode 3.2. To fix it, I copied UnicodeData.txt (conveniently provided by perl-modules in /usr/share/perl/5.8.0/unicore/UnicodeData.txt) to the top of unpacked python2.3 source package, renamed it to UnicodeData-Latest.txt, ran "python Tools/unicode/makeunicodedata.py" and then recompiled python2.3 package. This should probably be addressed upstream as well. before: >>> import unicodedata >>> unicodedata.name(u'\u20b0') Traceback (most recent call last): File "", line 1, in ? ValueError: no such name after: >>> import unicodedata >>> unicodedata.name(u'\u20b0') 'GERMAN PENNY SIGN' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 14:30 Message: Logged In: YES user_id=21627 Are you sure you are using the current CVS? In my copy of the CVS, renaming to UnicodeData-Latest is not necessary, and GERMANY PENNY SIGN is included in the database. To verify that you use the current CVS, please report the value of unicodedata.unidata_version. Fredrik, Debian has the Python 2.3 package only in its "unstable" (and "testing") distribution, see http://packages.debian.org/unstable/interpreters/python2.3.ht ml It is common to provide Debian packages for CVS versions of software in "unstable", so that the Debian developers can analyse effects of upcoming versions on their software. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 14:18 Message: Logged In: YES user_id=38376 Why is Debian shipping a "python2.3", when Python 2.3 hasn't been released yet (it's not even in alpha)? (the Unicode database in the current Python CVS has already been updated...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 From noreply@sourceforge.net Sun Dec 1 19:37:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 11:37:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-646408 ] old UnicodeData.txt Message-ID: Bugs item #646408, was opened at 2002-12-01 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: old UnicodeData.txt Initial Comment: [submitted at http://bugs.debian.org/171061] The version mentioned is CVS 021121 HEAD unicodedata.so is obviously built with older UnicodeData.txt file, and does not match new characters introduced in Unicode 3.2. To fix it, I copied UnicodeData.txt (conveniently provided by perl-modules in /usr/share/perl/5.8.0/unicore/UnicodeData.txt) to the top of unpacked python2.3 source package, renamed it to UnicodeData-Latest.txt, ran "python Tools/unicode/makeunicodedata.py" and then recompiled python2.3 package. This should probably be addressed upstream as well. before: >>> import unicodedata >>> unicodedata.name(u'\u20b0') Traceback (most recent call last): File "", line 1, in ? ValueError: no such name after: >>> import unicodedata >>> unicodedata.name(u'\u20b0') 'GERMAN PENNY SIGN' ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-12-01 19:37 Message: Logged In: YES user_id=60903 The CVS version (as mentioned) was 021121 HEAD. Closing the report, as this has changed six days ago. Frederik: Debian currently has 1.5, 2.1, 2.2 and 2.3, 2.1 beeing the default in the released (stable) distribution, and 2.2 the default in the "unstable" distribution. I did put 2.3 in unstable to ease building third party modules using the new version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 13:30 Message: Logged In: YES user_id=21627 Are you sure you are using the current CVS? In my copy of the CVS, renaming to UnicodeData-Latest is not necessary, and GERMANY PENNY SIGN is included in the database. To verify that you use the current CVS, please report the value of unicodedata.unidata_version. Fredrik, Debian has the Python 2.3 package only in its "unstable" (and "testing") distribution, see http://packages.debian.org/unstable/interpreters/python2.3.ht ml It is common to provide Debian packages for CVS versions of software in "unstable", so that the Debian developers can analyse effects of upcoming versions on their software. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 13:18 Message: Logged In: YES user_id=38376 Why is Debian shipping a "python2.3", when Python 2.3 hasn't been released yet (it's not even in alpha)? (the Unicode database in the current Python CVS has already been updated...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 From noreply@sourceforge.net Sun Dec 1 19:39:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 11:39:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-646578 ] Documentation Typo Message-ID: Bugs item #646578, was opened at 2002-12-01 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646578&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Monte Jeu (monte324) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation Typo Initial Comment: On this page there is an example of embedding Python into C. There is an error on the documentation. http://www.python.org/doc/current/ext/pureembedding.ht ml This line: $ call multiply 3 2 Should look like this $ call multiply multiply 3 2 The first multiply is the file name The second multiply is the function name ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646578&group_id=5470 From noreply@sourceforge.net Sun Dec 1 20:11:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 12:11:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-646592 ] netrc & special chars in passwords Message-ID: Bugs item #646592, was opened at 2002-12-01 20:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646592&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: netrc & special chars in passwords Initial Comment: [ from http://bugs.debian.org/168426 ] checked with 2.2.2 and CVS HEAD $ cat ~/.netrc machine localhost login ftp password my[pass >>> import netrc >>> n=netrc.netrc() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/netrc.py", line 80, in __init__ file, lexer.lineno) netrc.NetrcParseError: bad follower token '[' (/home/doko/.netrc, line 1) $ cat ~/.netrc machine localhost login ftp password "my[pass" is a workaround. Although on the netrc(5) "BSD File Formats Manual" page, I cannot find anything that enforces the quotes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646592&group_id=5470 From noreply@sourceforge.net Sun Dec 1 23:03:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 15:03:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-646707 ] {n} gets confused when teamed with (|) Message-ID: Bugs item #646707, was opened at 2002-12-01 18:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646707&group_id=5470 Category: Regular Expressions Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Rolf Campbell (endlisnis) Assigned to: Fredrik Lundh (effbot) Summary: {n} gets confused when teamed with (|) Initial Comment: Python 2.2.2 (#1, Nov 15 2002, 07:49:04) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.findall("(a|b|c|d){2}", "abcd") ['b', 'd'] expected ['ab', 'cd'] If I try that with grep: $ echo abcd | egrep -o '(a|b|c|d){2}' ab cd ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646707&group_id=5470 From noreply@sourceforge.net Mon Dec 2 00:44:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 16:44:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-02 01:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Håkan Waara (hwaara) Assigned to: Nobody/Anonymous (nobody) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 00:49:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 16:49:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-02 01:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Håkan Waara (hwaara) Assigned to: Nobody/Anonymous (nobody) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Håkan Waara (hwaara) Date: 2002-12-02 01:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 04:47:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 20:47:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-646578 ] Documentation Typo Message-ID: Bugs item #646578, was opened at 2002-12-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646578&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Monte Jeu (monte324) >Assigned to: Neal Norwitz (nnorwitz) Summary: Documentation Typo Initial Comment: On this page there is an example of embedding Python into C. There is an error on the documentation. http://www.python.org/doc/current/ext/pureembedding.ht ml This line: $ call multiply 3 2 Should look like this $ call multiply multiply 3 2 The first multiply is the file name The second multiply is the function name ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-01 23:47 Message: Logged In: YES user_id=33168 Correct, except the URL has is pure-embedding. :-) Thanks! Checked in as Doc/ext/embedding.tex 1.8 and 1.4.6.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646578&group_id=5470 From noreply@sourceforge.net Mon Dec 2 04:50:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 20:50:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-01 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 9 Submitted By: Håkan Waara (hwaara) Assigned to: Nobody/Anonymous (nobody) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-01 23:50 Message: Logged In: YES user_id=33168 Can you try the version from idlefork? See idlefork.sf.net. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-01 19:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 09:12:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 01:12:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-01 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 07:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 00:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Mon Dec 2 09:42:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 01:42:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-646707 ] {n} gets confused when teamed with (|) Message-ID: Bugs item #646707, was opened at 2002-12-02 00:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646707&group_id=5470 Category: Regular Expressions Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Rolf Campbell (endlisnis) Assigned to: Fredrik Lundh (effbot) Summary: {n} gets confused when teamed with (|) Initial Comment: Python 2.2.2 (#1, Nov 15 2002, 07:49:04) [GCC 2.95.3-5 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.findall("(a|b|c|d){2}", "abcd") ['b', 'd'] expected ['ab', 'cd'] If I try that with grep: $ echo abcd | egrep -o '(a|b|c|d){2}' ab cd ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-02 10:42 Message: Logged In: YES user_id=38376 egrep's (x) operator is spelled (?:x) in Python: >>> re.findall("(?:a|b|c|d)", "abcd") ['ab', 'cd'] The (x) form is used to create capturing groups. When a group matches in more than one place, only the last match is returned (the pattern inside the group can only match a single character, after all). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646707&group_id=5470 From noreply@sourceforge.net Mon Dec 2 10:58:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 02:58:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-448679 ] Left to right Message-ID: Bugs item #448679, was opened at 2001-08-07 08:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: Left to right Initial Comment: The Ref Man doesn't explicitly say anything about Python's left-to-right evaluation order. Strict left- to-right was Guido's intent, though, and it comes up a few times per year on c.l.py (indeed, I was just replying to a msg asking about it). The docs should get fleshed out. There's also a bug: >>> counter = 0 >>> def i(): ... global counter ... counter += 1 ... return counter ... >>> {i(): i()} {2: 1} >>> {i(): i(), i(): i()} {4: 3, 6: 5} >>> That is, key:value *pairs* are evaluated left to right, but within a single key:value pair, the value gets evaluated first. When I asked Guido about that some years ago, he agreed it was a bug. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 11:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it. It would be good to check that Jython meets all your expectations in this respect, and that it, in particular, executes all the examples in the documentation in the right order. This change should *not* be backported to 2.2 IMO. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 03:05 Message: Logged In: YES user_id=7887 Martin, could you please review the proposed solution? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-26 23:56 Message: Logged In: YES user_id=7887 I'm attaching a suggested solution for the problem, including documentation and reordering of dict evaluation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 11:58 Message: Logged In: YES user_id=21627 With the patch attached, this behaviour is cast into stone (or, atleast into a SF tracker :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470 From noreply@sourceforge.net Mon Dec 2 12:41:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 04:41:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-641111 ] Undocumented side effect of eval Message-ID: Bugs item #641111, was opened at 2002-11-20 08:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=641111&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Michael Hudson (mwh) Summary: Undocumented side effect of eval Initial Comment: Dictionary passed to eval as global name space is filled up with global variables: >>> m = {} >>> m == {} 1 >>> eval("1", m) 1 >>> m == {} 0 ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-11-29 20:30 Message: Logged In: YES user_id=593130 Without (cvs,) latex, and diff, I think cut-and-paste paste is about best I can do. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-25 15:06 Message: Logged In: YES user_id=6656 Make a patch & I'll check it in... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-11-24 22:42 Message: Logged In: YES user_id=593130 Suggestion: in Library Manual 2.1 eval() entry, after the second sentence, ending in 'local name space.', add If one give a *globals* dictionary that lacks a '__builtins__' entry, a copy from the current globals is added before *expession* is parsed. This means that *expression* normally has full access to the standard __builtins__ module, while restricted environments get propagated. This description is based on the tested behavior in 2.2.1. I don't know what, if any, is subject to change. (*Asterisks* indicate italics.) The 'surprise' of this side-effect has come up at least once on c.l.p. The issue of eval() and security is more frequent. The details are not obvious and occasionally important. I thus think it reasonable to add two short lines to document what happens. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-21 16:51 Message: Logged In: YES user_id=31435 Changed category to Doc and assigned to Fred, since there's no chance the implementation will change. I don't find the docs unclear, but this is deep stuff and it's certainly understanble that others may not. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-21 08:55 Message: Logged In: YES user_id=388573 I gues that a function don't have a side effect if the effect not documented. Why is dictionary passed as local name space not filled up with local variables? I think docs should say anything about this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-21 01:57 Message: Logged In: YES user_id=31435 Well, yes. That's what "global name space" means. Why would you assume it's limited to read-only? Where would you *expect* global bindings to be made, if not in the global namespace? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=641111&group_id=5470 From noreply@sourceforge.net Mon Dec 2 13:28:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 05:28:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-01 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 Category: None >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Ben Laurie (benl) Date: 2002-12-02 13:28 Message: Logged In: YES user_id=14333 This test was run against the current CVS. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 06:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Mon Dec 2 14:23:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 06:23:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-02 01:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 9 Submitted By: Håkan Waara (hwaara) Assigned to: Nobody/Anonymous (nobody) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Håkan Waara (hwaara) Date: 2002-12-02 15:23 Message: Logged In: YES user_id=72743 In idlefork it worked! Woo-hoo! And when I ran into an exception, even the "å" in "Håkan" was written out correctly. So this gotta mean that there's a patch waiting, if only the IDLE maintainers will accept it? How should we go forward? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 05:50 Message: Logged In: YES user_id=33168 Can you try the version from idlefork? See idlefork.sf.net. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 01:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 14:25:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 06:25:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-02 01:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 9 Submitted By: Håkan Waara (hwaara) Assigned to: Nobody/Anonymous (nobody) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Håkan Waara (hwaara) Date: 2002-12-02 15:25 Message: Logged In: YES user_id=72743 By the way, as a separate note... this is is how it looks: Traceback (innermost last) File "c:\documents and settings\håkan\skrivbord\guitest.py", line 22, in ? Shouldn't the path be case-sensitive? It's all-lowercase above, whereas it should have quite a few uppercase chars... However, I'm happy as long as it works! ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 15:23 Message: Logged In: YES user_id=72743 In idlefork it worked! Woo-hoo! And when I ran into an exception, even the "å" in "Håkan" was written out correctly. So this gotta mean that there's a patch waiting, if only the IDLE maintainers will accept it? How should we go forward? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 05:50 Message: Logged In: YES user_id=33168 Can you try the version from idlefork? See idlefork.sf.net. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 01:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 14:38:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 06:38:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-01 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open >Resolution: Fixed >Priority: 5 Submitted By: Håkan Waara (hwaara) >Assigned to: Neal Norwitz (nnorwitz) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 09:37 Message: Logged In: YES user_id=33168 Håkan, idlefork will be merged back into python. So after the merge, everything should be fine for python 2.2.3 and 2.3. I will leave this bug open until after the merge. As for the lower casing, I have no idea. If you have time, it would be great if you could test idlefork. An alpha release will be made soon, but the more testing it gets the better. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 09:25 Message: Logged In: YES user_id=72743 By the way, as a separate note... this is is how it looks: Traceback (innermost last) File "c:\documents and settings\håkan\skrivbord\guitest.py", line 22, in ? Shouldn't the path be case-sensitive? It's all-lowercase above, whereas it should have quite a few uppercase chars... However, I'm happy as long as it works! ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 09:23 Message: Logged In: YES user_id=72743 In idlefork it worked! Woo-hoo! And when I ran into an exception, even the "å" in "Håkan" was written out correctly. So this gotta mean that there's a patch waiting, if only the IDLE maintainers will accept it? How should we go forward? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-01 23:50 Message: Logged In: YES user_id=33168 Can you try the version from idlefork? See idlefork.sf.net. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-01 19:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 14:51:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 06:51:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-02 01:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Håkan Waara (hwaara) Assigned to: Neal Norwitz (nnorwitz) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Håkan Waara (hwaara) Date: 2002-12-02 15:51 Message: Logged In: YES user_id=72743 nnorwitz, thanks for your help. Should I file a bug about the lowercase issue? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 15:37 Message: Logged In: YES user_id=33168 Håkan, idlefork will be merged back into python. So after the merge, everything should be fine for python 2.2.3 and 2.3. I will leave this bug open until after the merge. As for the lower casing, I have no idea. If you have time, it would be great if you could test idlefork. An alpha release will be made soon, but the more testing it gets the better. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 15:25 Message: Logged In: YES user_id=72743 By the way, as a separate note... this is is how it looks: Traceback (innermost last) File "c:\documents and settings\håkan\skrivbord\guitest.py", line 22, in ? Shouldn't the path be case-sensitive? It's all-lowercase above, whereas it should have quite a few uppercase chars... However, I'm happy as long as it works! ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 15:23 Message: Logged In: YES user_id=72743 In idlefork it worked! Woo-hoo! And when I ran into an exception, even the "å" in "Håkan" was written out correctly. So this gotta mean that there's a patch waiting, if only the IDLE maintainers will accept it? How should we go forward? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 05:50 Message: Logged In: YES user_id=33168 Can you try the version from idlefork? See idlefork.sf.net. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 01:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 14:54:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 06:54:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-646730 ] Can't run script from IDLE Message-ID: Bugs item #646730, was opened at 2002-12-01 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 Category: IDLE Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Håkan Waara (hwaara) Assigned to: Neal Norwitz (nnorwitz) Summary: Can't run script from IDLE Initial Comment: When I try to run any of my scripts from the IDLE GUI, in Windows, through the Edit>Run Scipt menuitem, all I get is this error: >>> Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\ScriptBinding.py", line 151, in run_script_event interp.execfile(filename) File "C:\Python22\Tools\idle\PyShell.py", line 178, in execfile code = compile(source, filename, "exec") UnicodeError: ASCII encoding error: ordinal not in range (128) I checked the stack-trace, and saw that the "ordinal" it's complaining about must be the "å" in my Windows user name. IMHO, I should be able to run scripts even if my user name isn't all ASCII ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 09:54 Message: Logged In: YES user_id=33168 If you think it's important, I suppose. I don't find it that important. But I have no idea how difficult it is to fix. If it was simple, I would want it fixed. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 09:51 Message: Logged In: YES user_id=72743 nnorwitz, thanks for your help. Should I file a bug about the lowercase issue? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 09:37 Message: Logged In: YES user_id=33168 Håkan, idlefork will be merged back into python. So after the merge, everything should be fine for python 2.2.3 and 2.3. I will leave this bug open until after the merge. As for the lower casing, I have no idea. If you have time, it would be great if you could test idlefork. An alpha release will be made soon, but the more testing it gets the better. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 09:25 Message: Logged In: YES user_id=72743 By the way, as a separate note... this is is how it looks: Traceback (innermost last) File "c:\documents and settings\håkan\skrivbord\guitest.py", line 22, in ? Shouldn't the path be case-sensitive? It's all-lowercase above, whereas it should have quite a few uppercase chars... However, I'm happy as long as it works! ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-02 09:23 Message: Logged In: YES user_id=72743 In idlefork it worked! Woo-hoo! And when I ran into an exception, even the "å" in "Håkan" was written out correctly. So this gotta mean that there's a patch waiting, if only the IDLE maintainers will accept it? How should we go forward? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-01 23:50 Message: Logged In: YES user_id=33168 Can you try the version from idlefork? See idlefork.sf.net. ---------------------------------------------------------------------- Comment By: Håkan Waara (hwaara) Date: 2002-12-01 19:49 Message: Logged In: YES user_id=72743 More info. Here's the path to my script, in Windows: * C:\Documents and Settings\Håkan\Skrivbord\guitest.py and here it is, kind of thrashed, as I intercepted it in the stack trace: * u'C:\Documents and Settings\H\xe5kan\Skrivbord\guitest.py' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646730&group_id=5470 From noreply@sourceforge.net Mon Dec 2 22:19:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 14:19:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-636313 ] --with-dl-dld section of the readme Message-ID: Bugs item #636313, was opened at 2002-11-10 20:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636313&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Martin v. Löwis (loewis) Summary: --with-dl-dld section of the readme Initial Comment: [Related to question that was asked on python-help] The --with-dl-dld section of the readme could probably come out. The URLs in it point to files that don't exist any longer and the chances of fixing them seems small since pretty well the only references that Google finds to dl-dld-1.1.tar.Z are to copies of the README. Even if the files could be found, the number of people who want to fake up dynamic linking on platforms that don't support it natively is probably pretty small these days. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 23:19 Message: Logged In: YES user_id=21627 The options is now unsupported in configure.in 1.373, README 1.160 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:27 Message: Logged In: YES user_id=21627 If so, we should probably deprecate --with-dl-dld. I have added this to PEP 11, which means that a deprecation notice will be added in Python 2.3, with the feature being removed in Python 2.4. I'll leave this report open; when I get to incorporating all deprecated features into configure, I will add a notice into the README as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636313&group_id=5470 From noreply@sourceforge.net Mon Dec 2 23:31:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 15:31:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-03 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Dave Schuyler (parameter) >Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-23 15:46 Message: Logged In: YES user_id=14198 Sorry Tim, but you are the Windows build god . I assume this wont be looked at until closer to an RC, which is fine by me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-09 15:22 Message: Logged In: YES user_id=14198 OK - here we go :) Attaching a hack to try and get SSL working without too much pain! There is a .py file that attempts to locate an OpenSSL installation to use. As these seem to be released often, the script looks for the latest non-beta OpenSSL directory. If the OpenSSL directory does not have makefiles, it attempts to generate these makefiles (which uses Perl). Unfortunately, you need ActivePerl for this to work, and I try and make some effort towards ensuring a working perl is found and is used. Once done, this script then simply invokes a makefile to build the SSL module itself. An integrated patch will come after feedback. But for now, to test this you can: * Download and install OpenSSL, and install this in the same place other libs used by Python are installed, such as zlib. This should be in the "..\.." directory relative to the "PCBuild" directory. * Ensure ActivePerl is installed on your box, and is either on your path, or in "\perl\bin" or "c:\perl\bin" * Install the 3 files in this patch (_ssl.mak, build_ssl.py and _ssl.dsp) in the "PCBuild" directory. * In your Python MSVC workspace, add this new "_ssl.dsp" as a project, and make it depend on the "pythoncore" project. * Build the new project. If all goes well, OpenSSL will be configured and have makefiles generated, be built, and then have the _ssl.pyd module built. Lemme know how it goes! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-04 15:28 Message: Logged In: YES user_id=163326 I've successfully built socket.pyd against OpenSSL on win32: Build OpenSSL: read the README that's included. You basically need Perl and I also use NASM to build the highly optimized version of it. Add the OpenSSL include path (inc32, IIRC) for the socket module. Add the OpenSSL library path (lib32, IIRC) for the socket module. Add the two .lib files that can be found in lib32 to the libraries to link against. I think this is all that's involved. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-03 12:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Tue Dec 3 00:26:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 16:26:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-647387 ] Minor corrections to "What's new in 2.3" Message-ID: Bugs item #647387, was opened at 2002-12-03 00:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=647387&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Minor corrections to "What's new in 2.3" Initial Comment: Many thanks for the section "PEP 282: The logging Package" in "What's New in Python 2.3". It's a great introduction to the package - clear and concise. Some minor corrections/clarifications: The root logger is named "root" in the implementation, but it cannot be accessed by logging.getLogger("root") which would return a different non-root logger named "root". The correct way of getting the root logger is logging.getLogger("") or logging.getLogger(None). It's a bit of a wart, but naming the root logger as "" (which I thought of doing) would show an empty logger name in logging output when formatted with %(name)s, which I thought might be confusing. I'm not sure how to resolve it, but for now perhaps you could omit the clause 'with the name "root"' in the last sentence of paragraph 2? In the first lot of logging output shown, the warning message should be "WARN:root:Warning: config file server.conf not found" (the filename is missing in your example). In the penultimate paragraph, the propagate value should be false rather than true (if you want to prevent propagation up the logger hierarchy). Thanks & Regards, Vinay Sajip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=647387&group_id=5470 From noreply@sourceforge.net Tue Dec 3 00:27:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 16:27:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-647387 ] Minor corrections to "What's new in 2.3" Message-ID: Bugs item #647387, was opened at 2002-12-03 00:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=647387&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) >Assigned to: A.M. Kuchling (akuchling) >Summary: Minor corrections to "What's new in 2.3" Initial Comment: Many thanks for the section "PEP 282: The logging Package" in "What's New in Python 2.3". It's a great introduction to the package - clear and concise. Some minor corrections/clarifications: The root logger is named "root" in the implementation, but it cannot be accessed by logging.getLogger("root") which would return a different non-root logger named "root". The correct way of getting the root logger is logging.getLogger("") or logging.getLogger(None). It's a bit of a wart, but naming the root logger as "" (which I thought of doing) would show an empty logger name in logging output when formatted with %(name)s, which I thought might be confusing. I'm not sure how to resolve it, but for now perhaps you could omit the clause 'with the name "root"' in the last sentence of paragraph 2? In the first lot of logging output shown, the warning message should be "WARN:root:Warning: config file server.conf not found" (the filename is missing in your example). In the penultimate paragraph, the propagate value should be false rather than true (if you want to prevent propagation up the logger hierarchy). Thanks & Regards, Vinay Sajip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=647387&group_id=5470 From noreply@sourceforge.net Tue Dec 3 01:27:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 17:27:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-02 05:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-03 12:27 Message: Logged In: YES user_id=250749 What FreeBSD version is this on? (I assume the reference to "current CVS" means Python's CVS head). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-03 00:28 Message: Logged In: YES user_id=14333 This test was run against the current CVS. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 17:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 10:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Tue Dec 3 04:14:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 20:14:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-02 22:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific Status: Open >Resolution: Accepted Priority: 5 Submitted By: Dave Schuyler (parameter) Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-02 23:14 Message: Logged In: YES user_id=31435 Check it in -- that's a good way to force the issue. I certainly approve of the concept . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-23 01:46 Message: Logged In: YES user_id=14198 Sorry Tim, but you are the Windows build god . I assume this wont be looked at until closer to an RC, which is fine by me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-09 01:22 Message: Logged In: YES user_id=14198 OK - here we go :) Attaching a hack to try and get SSL working without too much pain! There is a .py file that attempts to locate an OpenSSL installation to use. As these seem to be released often, the script looks for the latest non-beta OpenSSL directory. If the OpenSSL directory does not have makefiles, it attempts to generate these makefiles (which uses Perl). Unfortunately, you need ActivePerl for this to work, and I try and make some effort towards ensuring a working perl is found and is used. Once done, this script then simply invokes a makefile to build the SSL module itself. An integrated patch will come after feedback. But for now, to test this you can: * Download and install OpenSSL, and install this in the same place other libs used by Python are installed, such as zlib. This should be in the "..\.." directory relative to the "PCBuild" directory. * Ensure ActivePerl is installed on your box, and is either on your path, or in "\perl\bin" or "c:\perl\bin" * Install the 3 files in this patch (_ssl.mak, build_ssl.py and _ssl.dsp) in the "PCBuild" directory. * In your Python MSVC workspace, add this new "_ssl.dsp" as a project, and make it depend on the "pythoncore" project. * Build the new project. If all goes well, OpenSSL will be configured and have makefiles generated, be built, and then have the _ssl.pyd module built. Lemme know how it goes! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-04 01:28 Message: Logged In: YES user_id=163326 I've successfully built socket.pyd against OpenSSL on win32: Build OpenSSL: read the README that's included. You basically need Perl and I also use NASM to build the highly optimized version of it. Add the OpenSSL include path (inc32, IIRC) for the socket module. Add the OpenSSL library path (lib32, IIRC) for the socket module. Add the two .lib files that can be found in lib32 to the libraries to link against. I think this is all that's involved. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-02 22:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Tue Dec 3 06:36:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 22:36:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-03 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific >Status: Pending Resolution: Accepted Priority: 5 Submitted By: Dave Schuyler (parameter) Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-12-03 17:36 Message: Logged In: YES user_id=14198 OK - all checked in and ready to close once the dust settles. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-03 15:14 Message: Logged In: YES user_id=31435 Check it in -- that's a good way to force the issue. I certainly approve of the concept . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-23 15:46 Message: Logged In: YES user_id=14198 Sorry Tim, but you are the Windows build god . I assume this wont be looked at until closer to an RC, which is fine by me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-09 15:22 Message: Logged In: YES user_id=14198 OK - here we go :) Attaching a hack to try and get SSL working without too much pain! There is a .py file that attempts to locate an OpenSSL installation to use. As these seem to be released often, the script looks for the latest non-beta OpenSSL directory. If the OpenSSL directory does not have makefiles, it attempts to generate these makefiles (which uses Perl). Unfortunately, you need ActivePerl for this to work, and I try and make some effort towards ensuring a working perl is found and is used. Once done, this script then simply invokes a makefile to build the SSL module itself. An integrated patch will come after feedback. But for now, to test this you can: * Download and install OpenSSL, and install this in the same place other libs used by Python are installed, such as zlib. This should be in the "..\.." directory relative to the "PCBuild" directory. * Ensure ActivePerl is installed on your box, and is either on your path, or in "\perl\bin" or "c:\perl\bin" * Install the 3 files in this patch (_ssl.mak, build_ssl.py and _ssl.dsp) in the "PCBuild" directory. * In your Python MSVC workspace, add this new "_ssl.dsp" as a project, and make it depend on the "pythoncore" project. * Build the new project. If all goes well, OpenSSL will be configured and have makefiles generated, be built, and then have the _ssl.pyd module built. Lemme know how it goes! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-04 15:28 Message: Logged In: YES user_id=163326 I've successfully built socket.pyd against OpenSSL on win32: Build OpenSSL: read the README that's included. You basically need Perl and I also use NASM to build the highly optimized version of it. Add the OpenSSL include path (inc32, IIRC) for the socket module. Add the OpenSSL library path (lib32, IIRC) for the socket module. Add the two .lib files that can be found in lib32 to the libraries to link against. I think this is all that's involved. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-03 12:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Tue Dec 3 13:36:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 05:36:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-647387 ] Minor corrections to "What's new in 2.3" Message-ID: Bugs item #647387, was opened at 2002-12-02 19:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=647387&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: A.M. Kuchling (akuchling) >Summary: Minor corrections to "What's new in 2.3" Initial Comment: Many thanks for the section "PEP 282: The logging Package" in "What's New in Python 2.3". It's a great introduction to the package - clear and concise. Some minor corrections/clarifications: The root logger is named "root" in the implementation, but it cannot be accessed by logging.getLogger("root") which would return a different non-root logger named "root". The correct way of getting the root logger is logging.getLogger("") or logging.getLogger(None). It's a bit of a wart, but naming the root logger as "" (which I thought of doing) would show an empty logger name in logging output when formatted with %(name)s, which I thought might be confusing. I'm not sure how to resolve it, but for now perhaps you could omit the clause 'with the name "root"' in the last sentence of paragraph 2? In the first lot of logging output shown, the warning message should be "WARN:root:Warning: config file server.conf not found" (the filename is missing in your example). In the penultimate paragraph, the propagate value should be false rather than true (if you want to prevent propagation up the logger hierarchy). Thanks & Regards, Vinay Sajip ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 08:36 Message: Logged In: YES user_id=11375 Applied to CVS; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=647387&group_id=5470 From noreply@sourceforge.net Tue Dec 3 14:01:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 06:01:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-569668 ] LINKCC incorrectly set Message-ID: Bugs item #569668, was opened at 2002-06-16 11:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470 Category: Build Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dr Leonid A Timochouk (cardou) Assigned to: A.M. Kuchling (akuchling) Summary: LINKCC incorrectly set Initial Comment: I was building Python 2.2.1 on Debian/GNU Linux 3.0 (testing pre-release) with gcc and g++ of version 3.0.4, using --with-cxx=g++ configure option. Then linking of the "python" executable fails due to an unresolved symbol (__gxx_personality_v0) in Modules/ccpython.o, because linking is still done with gcc: LINKCC is set to gcc ($CC) by configure, rather than to g++ ($CXX). The configure script attempts to determine the value of LINKCC and sets it to $CC if the latter can successfully link the simplest program "int main(){return 0;}" which was compiled with $CXX. In this case, linking apparently succeeds, setting LINKCC to $CC. Yet linking of Modules/ccpython.o with $CC fails, probably because Modules/ccpython.c is slightly more complex than the above configuration test, hence an extra unresolved symbol generated by g++. I am not sure how the correct value of LINKCC can be determined at config time without unnecessarily using $CXX all the time when it is available. Maybe the makefile should be modified so it always starts from $CC and falls through to $CXX if the former fails? Sincerely, Dr. Leonid Timochouk Computing Laboratory University of Kent at Canterbury England ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 09:01 Message: Logged In: YES user_id=11375 As Neal suggested, this problem seems to be fixed in Python 2.2.2 and 2.3CVS. Marking as closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 18:29 Message: Logged In: YES user_id=33168 I believe there were some changes made which should fix this problem. Can you try the latest CVS for the 2.2 branch or 2.3? cvs update -r release22-maint will get the 2.2.1+ version (what will become 2.2.2). Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470 From noreply@sourceforge.net Tue Dec 3 14:29:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 06:29:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-591287 ] makesetup fails: long Setup.local lines Message-ID: Bugs item #591287, was opened at 2002-08-05 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Sam Tannous (stannous) Assigned to: Nobody/Anonymous (nobody) Summary: makesetup fails: long Setup.local lines Initial Comment: makesetup fails: long Setup.local lines. I've included an attachment that describes the problem. Thanks, Sam Tannous (employees.org) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 09:29 Message: Logged In: YES user_id=11375 It's not length; it's the '=' symbol. Modules/makesetup compares the line to '*=*', and if it matches, assumes it's a definition, like 'DESTLIB=foo'. That also matches your -DBYTE_ORDER=1234, though, so makesetup just copies the line verbatim into the definition section. I don't see how to fix it, though; shell pattern matching doesn't seem powerful enough to do something like [^ ]*=*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:17:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:17:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-223261 ] string.split Message-ID: Bugs item #223261, was opened at 2000-11-23 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223261&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: string.split Initial Comment: Hi, The following program: #!/usr/bin/python import string print len(string.split('', ' ')) print len(string.split(' ', ' ')) prints: 1 2 This is of course sort of an undefined case, but I think it should be: 0 0 or at the very least: 0 1 Perl always prints 0. ---------------------------------------------------------------------- Comment By: David Jeske (jeske) Date: 2002-12-03 18:17 Message: Logged In: YES user_id=7266 The fact that it is documented does not make it useful. I wouldn't argue for Perl's strange behavior, however, it is strange that splitting an empty string behaves differently when providing an explicit split paramater... string.split("") --> [] string.split("",",") --> [""] This behavior is both non-intuitive, and non-useful... for example, this loop is bad: a = "1,2,3" b = "," for a_item in string.split(a,b): print int(a_item) Because if a is empty and b is not None, then there is an edge case where you have to handle an empty string falling through. This should not be the case. Doing string.split("",B) should ALWAYS result in the empty list. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-11-26 23:01 Message: Closed as Not-a-Bug; see /F's remarks. Note that Perl special-cases the snot out of a single blank used as a separator: "As a special case, specifying a PATTERN of space (' ') will split on white space just as split() with no arguments does. Thus, split(' ') can be used to emulate awk's default behavior, whereas split(/ /) will give you as many null initial fields as there are leading spaces. A split() on /\s+/ is like a split(' ') except that any leading whitespace produces a null first field. A split() with no arguments really does a split(' ', $_) internally." That's why Perl acts so differently -- it's not splitting on a single blank at all! Try splitting on / / in Perl and see what happens (which *really* splits on a blank): @a = split / /, " "; @b = split / /, ""; $a = @a; $b = @b; print "$a $b\n"; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-11-25 17:47 Message: not a bug: it's behaving exactly as defined by the documentation: If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223261&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:19:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:19:35 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-641415 ] xml.dom.minidom.toxml() & encoding Message-ID: Feature Requests item #641415, was opened at 2002-11-20 20:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=641415&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Xavier BASSERY (balthus) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.toxml() & encoding Initial Comment: Hi, when I use toxml() from an object resulting from a parseString() call, the string forgets the encoding option I've put in it first. Eg, I write this : >>> from xml.dom.minidom import parseString >>> dom = parseString("""\ ... nothing""") >>> print dom.toxml() nothing The output string has lost its encoding specification. So I took a look at the way toxml() was written and I've seen that it was calling writexml which do this bad thing (IMHO) : def writexml(self, writer, indent="", addindent="", newl=""): writer.write('\n') So would it be possible to memorize the options of the xml in the dom variable ? Or at list to give in toxml() a parameter (with '\n' as the default value) that will be used to write the beginning of the xml string ? Xavier ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 19:19 Message: Logged In: YES user_id=21627 Memorizing the encoding from the input is not possible, since the parser won't report what the encoding was. However, With Python 2.3 or PyXML 0.8.1, the toxml method now takes an optional encoding= parameter which allows you to specify the output encoding. Closing this feature request as Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=641415&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:24:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:24:20 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-644940 ] Support file path concat with "/" Message-ID: Feature Requests item #644940, was opened at 2002-11-27 21:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark VanTassel (markvantassel) Assigned to: Nobody/Anonymous (nobody) >Summary: Support file path concat with "/" Initial Comment: A very useful feature is to overload the "/" operator for strings to support path concatenation - that is, to concat the left and right arguments in such a way that there is exactly one slash between them, regardless of which argument(s) did or didn't include slashes: dir = "/this/that" file = "whatever.py" print dir / file #prints "/this/that/whatever.py" It seems silly, but when you're not 100% in control of things (such as when reading paths from config files, user input, etc), it's great to be sure that the right thing will happen without writing/testing a lot of icky code. And even when you are 100% in control, it's nice to not have to worry about it so much. This doesn't seem to conflict with any existing usage or syntax, so I don't think it can possibly break any existing behaviour (except, of course, those who were counting on having an exception thrown!) I've already coded this as a minor tweak to the Python 2.2.2 release, and I'd be happy to share the fix with the powers that be, if there's general concensus that this is a good thing. Feedback is solicited and appreciated (this is my first foray into open-source development, so be gentle!) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 19:24 Message: Logged In: YES user_id=21627 Please notice that there is an established function in Python that has the same effect: os.path.join: >>> dir = "/this/that" >>> file = "whatever.py" >>> import os >>> print os.path.join(dir,file) /this/that/whatever.py There is, in general, reluctance to add new syntax to Python if you can achieve the same effect with a function - in particular if the function has been there for a long time. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 21:00 Message: Logged In: YES user_id=33168 How often do you really need this? Is it that bad/hard to use os.path.join? There are always problems with adding new features which overload existing operations, like using "/". It's true that it would raise an exception today, so could be acceptable to implement str / str. However, unless this is for a very common task, is it worth it? Using / to join path components is not obvious to me. I doubt it would be generally obvious. Would it be confusing? There is the cost of not being able to use / for something possibly more meaningful and more common if this were implemented. ---------------------------------------------------------------------- Comment By: Mark VanTassel (markvantassel) Date: 2002-11-29 14:02 Message: Logged In: YES user_id=658048 Having used a C++ string class with overloaded "/", I can assure you it's quite useful. Aside from the executable being about 100 bytes larger, I can't see how it hurts anything. The righthandside absolute path (assuming you mean with a non-empty leftside path) is a semantic problem. You could reasonably say that if the right side starts with a slash, ignore the left side. Similarly, if the rightside starts with "X:" (under windows), ignore the left side. The Mac version could certainly insert ":" chars instead of slashes. Note, though, that the "/" operator isn't intended to solve all the worlds problems - if you have quirky path-usage rules, you'll probably have to implement them yourself regardless. This is just to make the relatively simple stuff (hopefully the 80% case) drop-dead simple and avoid strange errors when the user improperly specifies a directory (or a file) in a config file or whatever. URLs are a more intriguing issue - they were far less important the first time I implemented this. I suppose a subclass would be best. And while OS-specific flavors might be nice add-ons (for those rare cases when a Mac is concatenating paths meant for evaluation on a windows machine, etc), I strongly believe that the "default" behaviour should be appropriate for the current OS, thereby promoting code portability. Question: Would it be too ugly (or too difficult) to have a prefix character (analogous to the "r" for raw strings) to specify that a literal string is of one of the above-suggested subtypes? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-29 10:46 Message: Logged In: YES user_id=45365 Apart from the question of whether pathname concatenation is important enough to add a special operator on the string type for (I think not), there are lots of boundary issues with your proposal. For instance, how about a righthandside absolute path? How about two paths with C: style disks in them on Windows? How about Macintosh pathnames (colon-separated, with relative paths starting with a colon)? Or, why does it concatenate pathnames in the first place, and not URLs (makes a difference on Mac)? If you want to continue down this trail I would suggest the first step is to subclass strings. You can then have separate subclasses for Windows paths, Unix paths, URLs, Mac paths, etc. ---------------------------------------------------------------------- Comment By: Mark VanTassel (markvantassel) Date: 2002-11-27 21:49 Message: Logged In: YES user_id=658048 P.S. There are a few loose ends for discussion: 1) What to do with empty strings? My current implementation doesn't do anything special, so dir/"" ends with a slash, ""/file starts with a slash, and ""/"" is a slash. If someone thinks different behaviour would be better, I'm open to alternatives. 2) What about back slashes on Windows (my native platform, actually)? My version removes trailing slashes and backslashes from the 1st arg, and removes leading slashes and backslashes from the 2nd ard, and then puts a backslash between them... but again I'm open to alternatives. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:51:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:51:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-534748 ] Removing _tkinter considered harmful Message-ID: Bugs item #534748, was opened at 2002-03-25 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul F. Dubois (dubois) >Assigned to: A.M. Kuchling (akuchling) Summary: Removing _tkinter considered harmful Initial Comment: The Python build process now tries to import _tkinter and if it cannot removes it. There are two problems with this: a. It isn't correct. b. It removes the very thing required to understand why it won't import. (a) It isn't correct because it might import correctly later. If the user has, for example, installed tk / tcl in a place that is not in LD_LIBRARY_PATH, the import might fail during the Python build but succeed after the user sets this variable. Since the installer having it set is no guarantee the user will have it set, we aren't buying anything by verifying that the installer can import it. (b) If it won't import you just destroyed the evidence. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 13:51 Message: Logged In: YES user_id=11375 It didn't get ported to 2.2.2, either, or to the release22-maint branch. Should it be backported? (If not, this bug can be closed as "fixed in 2.3".) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-26 10:52 Message: Logged In: YES user_id=6656 The time machine strikes again; that's what happens in CVS Python (on the trunk; this didn't get ported to 221). ---------------------------------------------------------------------- Comment By: Paul F. Dubois (dubois) Date: 2002-04-26 10:38 Message: Logged In: YES user_id=5550 I now know that this is in Python's setup.py file. I suggest the offending file might be renamed rather than removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:53:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:53:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-534748 ] Removing _tkinter considered harmful Message-ID: Bugs item #534748, was opened at 2002-03-25 16:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul F. Dubois (dubois) Assigned to: A.M. Kuchling (akuchling) Summary: Removing _tkinter considered harmful Initial Comment: The Python build process now tries to import _tkinter and if it cannot removes it. There are two problems with this: a. It isn't correct. b. It removes the very thing required to understand why it won't import. (a) It isn't correct because it might import correctly later. If the user has, for example, installed tk / tcl in a place that is not in LD_LIBRARY_PATH, the import might fail during the Python build but succeed after the user sets this variable. Since the installer having it set is no guarantee the user will have it set, we aren't buying anything by verifying that the installer can import it. (b) If it won't import you just destroyed the evidence. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-03 18:53 Message: Logged In: YES user_id=6656 Yes please! If you can look at #645383 at the same time, the more the merrier! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 18:51 Message: Logged In: YES user_id=11375 It didn't get ported to 2.2.2, either, or to the release22-maint branch. Should it be backported? (If not, this bug can be closed as "fixed in 2.3".) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-26 15:52 Message: Logged In: YES user_id=6656 The time machine strikes again; that's what happens in CVS Python (on the trunk; this didn't get ported to 221). ---------------------------------------------------------------------- Comment By: Paul F. Dubois (dubois) Date: 2002-04-26 15:38 Message: Logged In: YES user_id=5550 I now know that this is in Python's setup.py file. I suggest the offending file might be renamed rather than removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:56:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:56:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-223261 ] string.split Message-ID: Bugs item #223261, was opened at 2000-11-23 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223261&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: string.split Initial Comment: Hi, The following program: #!/usr/bin/python import string print len(string.split('', ' ')) print len(string.split(' ', ' ')) prints: 1 2 This is of course sort of an undefined case, but I think it should be: 0 0 or at the very least: 0 1 Perl always prints 0. ---------------------------------------------------------------------- Comment By: David Jeske (jeske) Date: 2002-12-03 18:56 Message: Logged In: YES user_id=7266 Here is a better definition of the problem. string.split and string.join are not reciprical in this case. a = [] b = string.split(string.join(a,","),",") assert a == b, "this is not reciprocal" Currently, b is equal to [""] ---------------------------------------------------------------------- Comment By: David Jeske (jeske) Date: 2002-12-03 18:17 Message: Logged In: YES user_id=7266 The fact that it is documented does not make it useful. I wouldn't argue for Perl's strange behavior, however, it is strange that splitting an empty string behaves differently when providing an explicit split paramater... string.split("") --> [] string.split("",",") --> [""] This behavior is both non-intuitive, and non-useful... for example, this loop is bad: a = "1,2,3" b = "," for a_item in string.split(a,b): print int(a_item) Because if a is empty and b is not None, then there is an edge case where you have to handle an empty string falling through. This should not be the case. Doing string.split("",B) should ALWAYS result in the empty list. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-11-26 23:01 Message: Closed as Not-a-Bug; see /F's remarks. Note that Perl special-cases the snot out of a single blank used as a separator: "As a special case, specifying a PATTERN of space (' ') will split on white space just as split() with no arguments does. Thus, split(' ') can be used to emulate awk's default behavior, whereas split(/ /) will give you as many null initial fields as there are leading spaces. A split() on /\s+/ is like a split(' ') except that any leading whitespace produces a null first field. A split() with no arguments really does a split(' ', $_) internally." That's why Perl acts so differently -- it's not splitting on a single blank at all! Try splitting on / / in Perl and see what happens (which *really* splits on a blank): @a = split / /, " "; @b = split / /, ""; $a = @a; $b = @b; print "$a $b\n"; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-11-25 17:47 Message: not a bug: it's behaving exactly as defined by the documentation: If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223261&group_id=5470 From noreply@sourceforge.net Tue Dec 3 23:44:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 15:44:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-648119 ] more email ASCII decoding errors Message-ID: Bugs item #648119, was opened at 2002-12-03 16:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: more email ASCII decoding errors Initial Comment: email package v2.4.3. A similar problem was reported and fixed in http://python.org/sf/621457 The problem is that when using the Header.Header class to create a header, and the header value contains non-ASCII data that can't be decoded, a UnicodeError is raised. This is a problem when using email to process SPAM (as I do in TMDA), as SPAM often does contain random non-ASCII data in its headers. Some way of handling these cases more gracefully, without provoking a UnicodeError is necessary. See the attached traceback.txt for an example. The tmda-mess.txt file referenced from traceback.txt is also attached in case you want to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 From noreply@sourceforge.net Tue Dec 3 23:46:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 15:46:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-648119 ] more email ASCII decoding errors Message-ID: Bugs item #648119, was opened at 2002-12-03 16:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: more email ASCII decoding errors Initial Comment: email package v2.4.3. A similar problem was reported and fixed in http://python.org/sf/621457 The problem is that when using the Header.Header class to create a header, and the header value contains non-ASCII data that can't be decoded, a UnicodeError is raised. This is a problem when using email to process SPAM (as I do in TMDA), as SPAM often does contain random non-ASCII data in its headers. Some way of handling these cases more gracefully, without provoking a UnicodeError is necessary. See the attached traceback.txt for an example. The tmda-mess.txt file referenced from traceback.txt is also attached in case you want to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 From noreply@sourceforge.net Wed Dec 4 04:22:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 20:22:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-02 22:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific >Status: Open Resolution: Accepted Priority: 5 Submitted By: Dave Schuyler (parameter) Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-03 23:22 Message: Logged In: YES user_id=31435 Great work, Mark! I hit some snags doing this stuff on Win98SE, but got it all working and checked in. There's no reason I can see to keep this report open anymore. BTW, is test_socket_ssl.py the only test we've got for this? It passes here, so if that's all there is, I can't think of anything else remaining to do. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-12-03 01:36 Message: Logged In: YES user_id=14198 OK - all checked in and ready to close once the dust settles. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-02 23:14 Message: Logged In: YES user_id=31435 Check it in -- that's a good way to force the issue. I certainly approve of the concept . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-23 01:46 Message: Logged In: YES user_id=14198 Sorry Tim, but you are the Windows build god . I assume this wont be looked at until closer to an RC, which is fine by me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-09 01:22 Message: Logged In: YES user_id=14198 OK - here we go :) Attaching a hack to try and get SSL working without too much pain! There is a .py file that attempts to locate an OpenSSL installation to use. As these seem to be released often, the script looks for the latest non-beta OpenSSL directory. If the OpenSSL directory does not have makefiles, it attempts to generate these makefiles (which uses Perl). Unfortunately, you need ActivePerl for this to work, and I try and make some effort towards ensuring a working perl is found and is used. Once done, this script then simply invokes a makefile to build the SSL module itself. An integrated patch will come after feedback. But for now, to test this you can: * Download and install OpenSSL, and install this in the same place other libs used by Python are installed, such as zlib. This should be in the "..\.." directory relative to the "PCBuild" directory. * Ensure ActivePerl is installed on your box, and is either on your path, or in "\perl\bin" or "c:\perl\bin" * Install the 3 files in this patch (_ssl.mak, build_ssl.py and _ssl.dsp) in the "PCBuild" directory. * In your Python MSVC workspace, add this new "_ssl.dsp" as a project, and make it depend on the "pythoncore" project. * Build the new project. If all goes well, OpenSSL will be configured and have makefiles generated, be built, and then have the _ssl.pyd module built. Lemme know how it goes! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-04 01:28 Message: Logged In: YES user_id=163326 I've successfully built socket.pyd against OpenSSL on win32: Build OpenSSL: read the README that's included. You basically need Perl and I also use NASM to build the highly optimized version of it. Add the OpenSSL include path (inc32, IIRC) for the socket module. Add the OpenSSL library path (lib32, IIRC) for the socket module. Add the two .lib files that can be found in lib32 to the libraries to link against. I think this is all that's involved. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-02 22:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Wed Dec 4 09:01:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 01:01:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-223261 ] string.split Message-ID: Bugs item #223261, was opened at 2000-11-23 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223261&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: string.split Initial Comment: Hi, The following program: #!/usr/bin/python import string print len(string.split('', ' ')) print len(string.split(' ', ' ')) prints: 1 2 This is of course sort of an undefined case, but I think it should be: 0 0 or at the very least: 0 1 Perl always prints 0. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-04 04:01 Message: Logged In: YES user_id=80475 However, it is reciprocal when: a = ['']. The current behavior is useful. Split means return the original string with pieces broken-off wherever there is a separator. So, doing string.split("",B) should ALWAYS result in [""]. Debate is moot. The current, documented behavior is what it is. ---------------------------------------------------------------------- Comment By: David Jeske (jeske) Date: 2002-12-03 13:56 Message: Logged In: YES user_id=7266 Here is a better definition of the problem. string.split and string.join are not reciprical in this case. a = [] b = string.split(string.join(a,","),",") assert a == b, "this is not reciprocal" Currently, b is equal to [""] ---------------------------------------------------------------------- Comment By: David Jeske (jeske) Date: 2002-12-03 13:17 Message: Logged In: YES user_id=7266 The fact that it is documented does not make it useful. I wouldn't argue for Perl's strange behavior, however, it is strange that splitting an empty string behaves differently when providing an explicit split paramater... string.split("") --> [] string.split("",",") --> [""] This behavior is both non-intuitive, and non-useful... for example, this loop is bad: a = "1,2,3" b = "," for a_item in string.split(a,b): print int(a_item) Because if a is empty and b is not None, then there is an edge case where you have to handle an empty string falling through. This should not be the case. Doing string.split("",B) should ALWAYS result in the empty list. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-11-26 18:01 Message: Closed as Not-a-Bug; see /F's remarks. Note that Perl special-cases the snot out of a single blank used as a separator: "As a special case, specifying a PATTERN of space (' ') will split on white space just as split() with no arguments does. Thus, split(' ') can be used to emulate awk's default behavior, whereas split(/ /) will give you as many null initial fields as there are leading spaces. A split() on /\s+/ is like a split(' ') except that any leading whitespace produces a null first field. A split() with no arguments really does a split(' ', $_) internally." That's why Perl acts so differently -- it's not splitting on a single blank at all! Try splitting on / / in Perl and see what happens (which *really* splits on a blank): @a = split / /, " "; @b = split / /, ""; $a = @a; $b = @b; print "$a $b\n"; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-11-25 12:47 Message: not a bug: it's behaving exactly as defined by the documentation: If the second argument sep is present and not None, it specifies a string to be used as the word separator. The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=223261&group_id=5470 From noreply@sourceforge.net Wed Dec 4 11:24:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 03:24:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-645594 ] for lin in file: file.tell() tells wrong Message-ID: Bugs item #645594, was opened at 2002-11-29 12:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: for lin in file: file.tell() tells wrong Initial Comment: Consider following piece of code: f = file("test.txt", "rb") pos = f.tell() for line in f: print "%u: '%s'" % (pos, line) pos = f.tell() During the code execution we have following result: 0 'Line 1' 63 'Line 2' 63 'Line 3' ... 63 'Line 9' However, following piece of code works fine: f = file("test.txt", "rb") while True: pos = f.tell() line = f.readline() if line == "": break print "%u: '%s'" % (pos, line) It prints: 0 'Line 1' 7 'Line 2' 14 'Line 3' ... 56 'Line 9' It seems a file iterator makes file.tell() to tell positions of some internal blocks used by the iterator. ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2002-12-04 14:24 Message: Logged In: YES user_id=388573 File.next() uses readahead buffer (8192 bytes for now). Calling file.seek() drops the buffer, but other operations don't. I think it's possible for file.tell() to return right result (I'll try to make a patch). But all these quirks should be documented. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-30 01:07 Message: Logged In: YES user_id=45365 Actually, all file operations behave the same (well, all: I tried one: readline():-): they behave as if the whole file has been read. I.e. file.readline() within a "for line in file" will return an empty string. If a file iterator behaves as if it has read the complete file at once on instantiation (never mind what it actually does: if it *behaves* as if this happens) I think this should just be documented and that's it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 19:57 Message: Logged In: YES user_id=31435 Possibly. Maybe something fancier could be done too, to give "expected" results. although I don't know how to approach that on Windows for text-mode files (byte arithmetic on seek/tell results doesn't work at all for those). I'd take it to Python-Dev. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 19:01 Message: Logged In: YES user_id=21627 Shouldn't tell raise an exception then? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 18:42 Message: Logged In: YES user_id=31435 "for x in file" does do its own chunking under the covers, for speed, and seek() and tell() are indeed not to be used on a file being iterated over in this way. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-29 17:46 Message: Logged In: YES user_id=388573 I'll try to dig in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 17:30 Message: Logged In: YES user_id=21627 Would you like to investigate this further? There is no need to, but if you find a solution and a patch, there is a better chance that this is fixed before 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 From noreply@sourceforge.net Wed Dec 4 13:27:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 05:27:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-04 13:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-14 01:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 21:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 21:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 21:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 21:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 15:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 15:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 20:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 20:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Dec 4 14:54:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 06:54:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 09:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 08:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Dec 4 15:12:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 07:12:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 10:12 Message: Logged In: YES user_id=11375 One "make distclean" later, out-of-the-tree builds work fine for me. How do they fail? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 09:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 08:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Dec 4 15:18:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 07:18:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-04 15:18 Message: Logged In: YES user_id=6656 OK, they don't actually break, but .o files end up in src/Modules/ rather than src/build-temp/build/temp.foo/ so multiple oot builds don't so what you'd expect. This came up on python-dev in the thread "extension module .o files wind up in the wrong place" starting here: http://mail.python.org/pipermail/python-dev/2002-December/030644.html ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 15:12 Message: Logged In: YES user_id=11375 One "make distclean" later, out-of-the-tree builds work fine for me. How do they fail? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 14:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 13:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-14 01:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 21:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 21:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 21:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 21:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 15:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 15:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 20:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 20:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Dec 4 18:13:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 10:13:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 13:13 Message: Logged In: YES user_id=11375 Now I get it. In an in-tree build, the source path is something relative, such as ../Modules/foo.c, but in an out-of-tree build it's absolute. This is due to a line in setup.py, but I can't remember why this is done. One fix that's an egregious hack is to modify CCompiler.object_filenames: if strip_dir is false and the path is absolute, strip off the path to the source directory; see the attached patch. The patch also modifies setup.py to leave the path names alone. I'll keep thinking about this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 10:18 Message: Logged In: YES user_id=6656 OK, they don't actually break, but .o files end up in src/Modules/ rather than src/build-temp/build/temp.foo/ so multiple oot builds don't so what you'd expect. This came up on python-dev in the thread "extension module .o files wind up in the wrong place" starting here: http://mail.python.org/pipermail/python-dev/2002-December/030644.html ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 10:12 Message: Logged In: YES user_id=11375 One "make distclean" later, out-of-the-tree builds work fine for me. How do they fail? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 09:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 08:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Wed Dec 4 22:04:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 14:04:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-648658 ] xmlrpc can't do proxied HTTP Message-ID: Bugs item #648658, was opened at 2002-12-04 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648658&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Bumgarner (bbum) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpc can't do proxied HTTP Initial Comment: The current xmlrpclib can't communicate through a proxy server. In particular, the two Transport classes contained within xmlrpclib use httplib directly and, as such, do not support the proxy handling as offered by urllib. Or so it seems. I'm in dire need of support for proxies in xmlrpclib and will be investigating creating a custom Transport class that uses urllib as opposed to httplib to gain support for proxies. Assuming success, I'll post the new transport class here. In the interim, I figured I would log a bug in case anyone else is interested in working on the problem (or already has a solution :). b.bum bbum@mac.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648658&group_id=5470 From noreply@sourceforge.net Wed Dec 4 22:09:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 14:09:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS Message-ID: Bugs item #416526, was opened at 2001-04-16 17:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470 Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: Regular expression tests: SEGV on Mac OS Initial Comment: The regular expression regression tests 'test_re' causes a SEGV failure on Mac OS X version 10.0.1 when using Python 2.1c2 (and earlier). This is caused by the test trying to recurse 50,000 levels deep. Workaround: A workaround is to limit how deep the regular expression library can recurse (this is already done for Win32). This can be achieved by changing file './Modules/_sre.c' using the following patch: --- ./orig/_sre.c Sun Apr 15 19:00:58 2001 +++ ./new/_sre.c Mon Apr 16 21:39:29 2001 @@ -75,6 +75,9 @@ Win64 (MS_WIN64), Linux64 (__LP64__), Monterey (64-bit AIX) (_LP64) */ /* FIXME: maybe the limit should be 40000 / sizeof(void*) ? */ #define USE_RECURSION_LIMIT 7500 +#elif defined(__APPLE_CC__) +/* Apple 'cc' compiler eg. for Mac OS X */ +#define USE_RECURSION_LIMIT 4000 #else #define USE_RECURSION_LIMIT 10000 #endif ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2002-12-04 17:09 Message: Logged In: YES user_id=103811 Bad workaround. A better workaround is to set a reasonable stacksize limite; the 'out of the box' stacksize limit is stupid low. Try running 'unlimit' before the regression tests -- the test will pass fine on OS X in that situation. Limiting the recursion limit on OS X simply because the [easily changed] out of the box stack size is relatively small would be a very bad fix indeed. I have run into a number of situations where I programatically generate regular expressions that can be extremely complex. They explode on OS X without the 'unlimit' and work fine once the stack has been set to a reasonable maximum size. I would be extremely unhappy if those expressions were to *always* break on OS X due to a change to the internals of python that assume the stack will always be tiny. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-19 01:16 Message: Logged In: NO same problem on 10.1.4 james@i-mech.com ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 23:49 Message: Logged In: YES user_id=6380 /F is unavailable, I don't want this to hold up the 2.2a2 release, so I'm lowering the priority because it doesn't affect Linux or Windows. (Remember, no bugs/patches with priority >= 7 should be left when doing a release.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-01 20:41 Message: Logged In: NO >An alternate (and perhaps better) workaround could be to increase the stack size on Mac OS X. it's been tried and shot down as a will not fix. :-( instead of +#elif defined(__APPLE_CC__) perhaps we should use __APPLE__ as per the documentation: There are two relatively new macros: __APPLE__ and __APPLE_CC__.The former refers to any Apple platform, though at present it is only predefined in Apple's gcc-based Mac OS X and Mac OS X Server compilers. The value of the latter is an integer that corresponds to the version number of the compiler. This should allow one to distinguish, for example, between compilers based on the same version of gcc, but with different bug fixes or features. At present, larger values denote (chronologically) later compilers. - D ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-26 18:01 Message: Logged In: YES user_id=38376 An alternate (and perhaps better) workaround could be to increase the stack size on Mac OS X. But in either case, my plan is to get rid of the recursion limit in 2.2 (stackless SRE may still run out of memory, but it shouldn't have to run out of stack). Cheers /F ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2001-04-17 19:52 Message: Logged In: YES user_id=80173 Instead of relying on a compiler variable, we should probably set a environment variable as part of the ./configure and use that to determine when to reduce the USE_RECURSION_LIMIT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470 From noreply@sourceforge.net Thu Dec 5 18:20:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 10:20:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-472881 ] distutils does not deduce dependencies Message-ID: Bugs item #472881, was opened at 2001-10-19 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: distutils does not deduce dependencies Initial Comment: I just "cvs up"d my Python tree and executed "make". Nothing much changed, except patchlevel.h. Make got this right and rebuilt everything (patchlevel.h is included from Python.h, so changing patchlevel.h should cause make to rebuild just about everything). Distutils failed to notice this, however, so it didn't rebuild any modules. In this case, I think the failure to rebuild is probably innocuous, but I'm not at all confident it will do the right thing if I modify some other file. For example, I've noticed that it's not sufficient to delete a module's .o file when you want to rebuild it. Distutils still thinks the .so file is okay. If distutils is going to take the place of make I think it's going to need to do a much better job deducing file dependencies or provide a robust way for a person to tell it what those dependencies are. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-05 18:20 Message: Logged In: YES user_id=6656 This has been sitting on my plate forever. AIUI, distutils can now be told about dependencies, but does nothing to deduce them itself. As this puts it in good company (eg, make), I reckon we can probably close this? At any rate, I don't see me getting to it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-23 10:28 Message: Logged In: YES user_id=6656 Umm, I didn't mean to close this. Oh well. TBH, I'm tempted to close it again, with a resolution of "wont fix", but am open to persuasion. I'm not sure I can summon the motivation to add dependency tracking to distutils. And I don't like the hack I've attached to the report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:16 Message: Logged In: YES user_id=6380 I agree. Let's put this off until 2.3 (or maybe 2.2.1). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 12:39 Message: Logged In: YES user_id=6656 Here's an attempt. TBH, I'd be a bit nervous about fiddling with the build at this stage, but assigning to Guido to decide. I'd recommend assigning it back to me Pending/Later, and applying something like this early in 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 15:49 Message: Logged In: YES user_id=6656 OK, I'll try to get something concrete done in the next few days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 14:54 Message: Logged In: YES user_id=6380 It depends on what kind of change you are making to a header file. 99% of the time I find that a change to a header is something innocuous like add a new function, and it still causes a rebuild of the world. That's particularly annoying when I'm experimenting with a new object type and adding things to the header file one at a time -- each time the header gets touched everything gets rebuilt. But it's easy enough to only rebuild the core ("make python") so I'm not sure if I really oppose your simple solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 13:53 Message: Logged In: YES user_id=6656 Eh, I was going to add a os.system("touch last_build") thingy to setup.py. Not aiming for elegance here. Is it really 99% of the time that changes in headers are irrelevant? Then what make does is a bit silly, surely. It would presumably be easy enough to ask the user, but I know I'd find that really annoying (I generally fire a biuld off, do something else for a few minutes and come back. OTOH, I almost always go through a "rm -rfv build && mkdir build && cd build && ../configure --prefix=$HOME && make" ritual anyway so this issue doesn't affect me in the slightest). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 13:40 Message: Logged In: YES user_id=6380 Hm, how do you know when the last build was? Also, since in 99% of the cases this is unnecessary and rebuilding all extensions takes a long time, I'd like this to be optional -- maybe it can ask the user before zapping build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-07 12:36 Message: Logged In: YES user_id=6656 Would a "good enough" solution be to check (in setup.py) if pyconfig.h or anything in Include/ has changed since the last build and if so blow away the & build directory? Doing a "proper" job seems frankly unlikely, and would have much the same effect as the above anyway for building Python... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=472881&group_id=5470 From noreply@sourceforge.net Thu Dec 5 19:32:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 11:32:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-649122 ] marshal/pickle problem with True/False Message-ID: Bugs item #649122, was opened at 2002-12-05 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shack Toms (shacktoms) Assigned to: Nobody/Anonymous (nobody) Summary: marshal/pickle problem with True/False Initial Comment: It appears that True and False are special cases of integer 1 and 0 such that... >>> True is 1 0 >>> False is 0 0 After pickling or marshaling, however, this specialness is lost. >>> pickle.loads(pickle.dumps(True)) is 1 1 >>> pickle.loads(pickle.dumps(True)) is True 0 >>> pickle.loads(pickle.dumps(False)) is 0 1 >>> pickle.loads(pickle.dumps(False)) is False 0 In other words, True is unpickled as a non-special 1 and False is unpicked as a non-special 0. It appears that the problem, the bug, is that neither pickle nor marshal distinguishes between True/False and 1/0. >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> marshal.dumps(True) == marshal.dumps(1) 1 >>> marshal.dumps(False) == marshal.dumps(0) 1 My version info... Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Microsoft Windows 2000 5.00.2195 Service Pack 3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 From noreply@sourceforge.net Thu Dec 5 19:39:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 11:39:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-649122 ] marshal/pickle problem with True/False Message-ID: Bugs item #649122, was opened at 2002-12-05 19:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Shack Toms (shacktoms) >Assigned to: Michael Hudson (mwh) Summary: marshal/pickle problem with True/False Initial Comment: It appears that True and False are special cases of integer 1 and 0 such that... >>> True is 1 0 >>> False is 0 0 After pickling or marshaling, however, this specialness is lost. >>> pickle.loads(pickle.dumps(True)) is 1 1 >>> pickle.loads(pickle.dumps(True)) is True 0 >>> pickle.loads(pickle.dumps(False)) is 0 1 >>> pickle.loads(pickle.dumps(False)) is False 0 In other words, True is unpickled as a non-special 1 and False is unpicked as a non-special 0. It appears that the problem, the bug, is that neither pickle nor marshal distinguishes between True/False and 1/0. >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> marshal.dumps(True) == marshal.dumps(1) 1 >>> marshal.dumps(False) == marshal.dumps(0) 1 My version info... Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Microsoft Windows 2000 5.00.2195 Service Pack 3 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-05 19:39 Message: Logged In: YES user_id=6656 I'm afraid you're a bit confused. In 2.2.x True and False are integers. They may not actually *be* the integers you get when you type 1 and 0, but they are still integers. If you try what you tried in a 2.3a0 build from CVS, you should see different answers. Applying identity (`is') to immutable objects is discouraged for exactly this sort of reason... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 From noreply@sourceforge.net Thu Dec 5 21:33:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 13:33:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-633152 ] list slice ass ignores subtypes of list Message-ID: Bugs item #633152, was opened at 2002-11-04 08:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Michael Hudson (mwh) Summary: list slice ass ignores subtypes of list Initial Comment: When assigning a subtype of list to a list slice the implementation of slice-assignment directly accesses the list representation and ignores any modified accessor functions: class MyList (list): def __getitem__(self, idx): if idx % 2 == 0: return 'E' return 'O' mylst = MyList() mylst.append(1) mylst.append(1) lst = [ 1, 2, 3, 4] lst [2:3] = mylst print lst # prints [1, 2, 1, 1, 4] I'd expect it to print [1, 2, 'E', 'O', 4 ] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-05 21:33 Message: Logged In: YES user_id=6656 Checked in Objects/listobject.c revision 2.142 Lib/test/test_types.py revision 1.43 to allow arbitrary sequences on the RHS of assignment to extended slices. Closing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-14 13:23 Message: Logged In: YES user_id=6656 Not sure :-/ Actually, the extended slices stuff should grow to accept non-lists on the RHS, so the report should stay open. What's less clear is whether tuple(list_subtype) should respect the subtype. There are so many places where the subtype is not respected, I'm inclined to leave it be. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 03:43 Message: Logged In: YES user_id=33168 Michael is there still a bug here or should this be closed? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-11 12:26 Message: Logged In: YES user_id=580910 I already have an NSArray proxy (actually a module that proxies the entire Cocoa classtree on MacOS X). The NSArray proxy is not a subclass of list but part of a class hierarchy that mirrors that of the proxied classes (the code is available from pyobjc.sourceforge.net). The reason I ran into this bug is that someone suggested that subclassing list might be a good solution for using an NSArray as the source for slice assigment on lists. Thanks to your previous patch that is no longer an issue. It might be usefull to add functions that check if it is save to directly access the list representation. Even though it might not be sensible to do so, it is possible to change __getitem__ et. al. from Python code and it would be very strange if the version of those methods from subclasses is sometimes ignored. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-11 11:50 Message: Logged In: YES user_id=6656 I've thought about this a bit. You're writing a NSArray proxy, right? Here's some advice: do NOT inherit from list. What does inheriting from list get you? The ability to pass `PyList_Check'. But almost inevitably code that calls that promptly pokes into the internal structure of the list. For example, you'll find iterating over your proxy list doesn't respect the subtype (unless you supply an __iter__ method, I guess/hope). If you find things that fail because of this, let's fix those to take more general sequences. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-06 11:21 Message: Logged In: YES user_id=6656 Sigh. More s/PyList_Check/PyList_CheckExact/ I guess. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-06 08:45 Message: Logged In: YES user_id=580910 Sorry, but it is not fixed completely. The problem is in PyList_AsTuple (called by PySequence_Tuple if the arguments is a PyList). PyList_AsTuple directly accesses the list representation, and therefore the code above still fails. I'll try to post a patch for this later this week. I'm not sure why the patch got corrupted, it (and still is) fine on my system (but not when I download it again...). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-05 18:15 Message: Logged In: YES user_id=6656 I think this is now fixed, via a somewhat different approach. You might want to check, though. While we're at it, there are a bunch of problems with your patch (for future reference): 1) it contains a bunch of NUL bytes! 2) it's a straight diff. we like context (-c) or unified (-u) diffs. most people prefer context diffs, I think. Bass players (e.g. Barry) prefer unified. 3) it has no error checking at all! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-04 11:04 Message: Logged In: YES user_id=580910 The attached patch (list_ass_slice.patch) updates the implementation of slice assigment for lists: If the RHS is a list (exact match) use the current implementation and if the RHS is a sequence use PySequence_GetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633152&group_id=5470 From noreply@sourceforge.net Thu Dec 5 22:26:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 14:26:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-649187 ] sqrt(-1) weirdness? Message-ID: Bugs item #649187, was opened at 2002-12-05 17:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649187&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: H. Richard Harkins (hrharkins) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(-1) weirdness? Initial Comment: I was justing playing around with some complex number stuff for kicks and ran across something I'm not sure about, not having playing with complex numbers for any real purpose for so long. Anyway, here's the scenario: >>> from math import sqrt >>> sqrt(-1) (Produces a ValueError) >>> -1 ** .5 -1.0 Shouldn't each of these produce (0+1j)? If not, shouldn't the second case produce ValueError too? It should be the case that -1.0 ** 2 == -1.0 ** .5, shouldn't it? Rich ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649187&group_id=5470 From noreply@sourceforge.net Thu Dec 5 22:30:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 14:30:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-649187 ] sqrt(-1) weirdness? Message-ID: Bugs item #649187, was opened at 2002-12-05 17:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649187&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: H. Richard Harkins (hrharkins) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(-1) weirdness? Initial Comment: I was justing playing around with some complex number stuff for kicks and ran across something I'm not sure about, not having playing with complex numbers for any real purpose for so long. Anyway, here's the scenario: >>> from math import sqrt >>> sqrt(-1) (Produces a ValueError) >>> -1 ** .5 -1.0 Shouldn't each of these produce (0+1j)? If not, shouldn't the second case produce ValueError too? It should be the case that -1.0 ** 2 == -1.0 ** .5, shouldn't it? Rich ---------------------------------------------------------------------- >Comment By: H. Richard Harkins (hrharkins) Date: 2002-12-05 17:30 Message: Logged In: YES user_id=283299 Okay, even weirder. Just tested my assertion above and Python says it's true! >>> -1.0 ** 2 -1.0 I just noticed Perl doing the same thing in this case. What gives here? Is this a libc library problem? (This is under RedHat 8 Linux kernel 2.4.18-14). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649187&group_id=5470 From noreply@sourceforge.net Thu Dec 5 22:51:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 14:51:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-649187 ] sqrt(-1) weirdness? Message-ID: Bugs item #649187, was opened at 2002-12-05 22:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649187&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: H. Richard Harkins (hrharkins) Assigned to: Nobody/Anonymous (nobody) Summary: sqrt(-1) weirdness? Initial Comment: I was justing playing around with some complex number stuff for kicks and ran across something I'm not sure about, not having playing with complex numbers for any real purpose for so long. Anyway, here's the scenario: >>> from math import sqrt >>> sqrt(-1) (Produces a ValueError) >>> -1 ** .5 -1.0 Shouldn't each of these produce (0+1j)? If not, shouldn't the second case produce ValueError too? It should be the case that -1.0 ** 2 == -1.0 ** .5, shouldn't it? Rich ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-12-05 22:51 Message: Logged In: YES user_id=35752 Not a bug. Try: (-1)**2 Regarding sqrt(-1), use: import cmath cmath.sqrt(-1) ---------------------------------------------------------------------- Comment By: H. Richard Harkins (hrharkins) Date: 2002-12-05 22:30 Message: Logged In: YES user_id=283299 Okay, even weirder. Just tested my assertion above and Python says it's true! >>> -1.0 ** 2 -1.0 I just noticed Perl doing the same thing in this case. What gives here? Is this a libc library problem? (This is under RedHat 8 Linux kernel 2.4.18-14). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649187&group_id=5470 From noreply@sourceforge.net Thu Dec 5 23:08:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 15:08:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-649122 ] marshal/pickle problem with True/False Message-ID: Bugs item #649122, was opened at 2002-12-05 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Shack Toms (shacktoms) Assigned to: Michael Hudson (mwh) Summary: marshal/pickle problem with True/False Initial Comment: It appears that True and False are special cases of integer 1 and 0 such that... >>> True is 1 0 >>> False is 0 0 After pickling or marshaling, however, this specialness is lost. >>> pickle.loads(pickle.dumps(True)) is 1 1 >>> pickle.loads(pickle.dumps(True)) is True 0 >>> pickle.loads(pickle.dumps(False)) is 0 1 >>> pickle.loads(pickle.dumps(False)) is False 0 In other words, True is unpickled as a non-special 1 and False is unpicked as a non-special 0. It appears that the problem, the bug, is that neither pickle nor marshal distinguishes between True/False and 1/0. >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> marshal.dumps(True) == marshal.dumps(1) 1 >>> marshal.dumps(False) == marshal.dumps(0) 1 My version info... Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Microsoft Windows 2000 5.00.2195 Service Pack 3 ---------------------------------------------------------------------- >Comment By: Shack Toms (shacktoms) Date: 2002-12-05 18:08 Message: Logged In: YES user_id=603293 True and False may be integers, but they are special in that they are Py_True and Py_False, internally. Why is this important? True and False are treated differently from 1 and 0 when converted to a variant by Mark Hammond's oleargs.cpp code, which specifically checks for Py_True and Py_False before checking for Integer-ness by calling PyInt_Check(). These values get converted to the VARIANT_BOOL type, with values 0xffff and 0. For this reason, it would be useful if their special "True" and "False" -ness could be preserved by pickling. >>> 1 == 1 1 >>> (1 == 1) is True 1 >>> (1 == 1) is 1 0 Because of the above, logical results get converted by Hammond's code to the correct VARIANT_BOOL types--but not after pickling. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-05 14:39 Message: Logged In: YES user_id=6656 I'm afraid you're a bit confused. In 2.2.x True and False are integers. They may not actually *be* the integers you get when you type 1 and 0, but they are still integers. If you try what you tried in a 2.3a0 build from CVS, you should see different answers. Applying identity (`is') to immutable objects is discouraged for exactly this sort of reason... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 From noreply@sourceforge.net Thu Dec 5 23:15:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 15:15:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-649122 ] marshal/pickle problem with True/False Message-ID: Bugs item #649122, was opened at 2002-12-05 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Invalid Priority: 5 Submitted By: Shack Toms (shacktoms) Assigned to: Michael Hudson (mwh) Summary: marshal/pickle problem with True/False Initial Comment: It appears that True and False are special cases of integer 1 and 0 such that... >>> True is 1 0 >>> False is 0 0 After pickling or marshaling, however, this specialness is lost. >>> pickle.loads(pickle.dumps(True)) is 1 1 >>> pickle.loads(pickle.dumps(True)) is True 0 >>> pickle.loads(pickle.dumps(False)) is 0 1 >>> pickle.loads(pickle.dumps(False)) is False 0 In other words, True is unpickled as a non-special 1 and False is unpicked as a non-special 0. It appears that the problem, the bug, is that neither pickle nor marshal distinguishes between True/False and 1/0. >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> marshal.dumps(True) == marshal.dumps(1) 1 >>> marshal.dumps(False) == marshal.dumps(0) 1 My version info... Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Microsoft Windows 2000 5.00.2195 Service Pack 3 ---------------------------------------------------------------------- Comment By: Shack Toms (shacktoms) Date: 2002-12-05 18:08 Message: Logged In: YES user_id=603293 True and False may be integers, but they are special in that they are Py_True and Py_False, internally. Why is this important? True and False are treated differently from 1 and 0 when converted to a variant by Mark Hammond's oleargs.cpp code, which specifically checks for Py_True and Py_False before checking for Integer-ness by calling PyInt_Check(). These values get converted to the VARIANT_BOOL type, with values 0xffff and 0. For this reason, it would be useful if their special "True" and "False" -ness could be preserved by pickling. >>> 1 == 1 1 >>> (1 == 1) is True 1 >>> (1 == 1) is 1 0 Because of the above, logical results get converted by Hammond's code to the correct VARIANT_BOOL types--but not after pickling. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-05 14:39 Message: Logged In: YES user_id=6656 I'm afraid you're a bit confused. In 2.2.x True and False are integers. They may not actually *be* the integers you get when you type 1 and 0, but they are still integers. If you try what you tried in a 2.3a0 build from CVS, you should see different answers. Applying identity (`is') to immutable objects is discouraged for exactly this sort of reason... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 From noreply@sourceforge.net Fri Dec 6 08:19:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 00:19:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-12-06 09:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 11:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 11:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Fri Dec 6 10:58:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 02:58:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-646408 ] old UnicodeData.txt Message-ID: Bugs item #646408, was opened at 2002-12-01 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 Category: Unicode Group: Python 2.3 Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: old UnicodeData.txt Initial Comment: [submitted at http://bugs.debian.org/171061] The version mentioned is CVS 021121 HEAD unicodedata.so is obviously built with older UnicodeData.txt file, and does not match new characters introduced in Unicode 3.2. To fix it, I copied UnicodeData.txt (conveniently provided by perl-modules in /usr/share/perl/5.8.0/unicore/UnicodeData.txt) to the top of unpacked python2.3 source package, renamed it to UnicodeData-Latest.txt, ran "python Tools/unicode/makeunicodedata.py" and then recompiled python2.3 package. This should probably be addressed upstream as well. before: >>> import unicodedata >>> unicodedata.name(u'\u20b0') Traceback (most recent call last): File "", line 1, in ? ValueError: no such name after: >>> import unicodedata >>> unicodedata.name(u'\u20b0') 'GERMAN PENNY SIGN' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-06 11:58 Message: Logged In: YES user_id=21627 It may not matter anymore, but... In the Debian package 2.2.94-1exp1, the changelog indicates that it was from CVS 021120. In that version, GERMANY PENNY SIGN is already in the Unicode database. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-12-01 20:37 Message: Logged In: YES user_id=60903 The CVS version (as mentioned) was 021121 HEAD. Closing the report, as this has changed six days ago. Frederik: Debian currently has 1.5, 2.1, 2.2 and 2.3, 2.1 beeing the default in the released (stable) distribution, and 2.2 the default in the "unstable" distribution. I did put 2.3 in unstable to ease building third party modules using the new version. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 14:30 Message: Logged In: YES user_id=21627 Are you sure you are using the current CVS? In my copy of the CVS, renaming to UnicodeData-Latest is not necessary, and GERMANY PENNY SIGN is included in the database. To verify that you use the current CVS, please report the value of unicodedata.unidata_version. Fredrik, Debian has the Python 2.3 package only in its "unstable" (and "testing") distribution, see http://packages.debian.org/unstable/interpreters/python2.3.ht ml It is common to provide Debian packages for CVS versions of software in "unstable", so that the Debian developers can analyse effects of upcoming versions on their software. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-01 14:18 Message: Logged In: YES user_id=38376 Why is Debian shipping a "python2.3", when Python 2.3 hasn't been released yet (it's not even in alpha)? (the Unicode database in the current Python CVS has already been updated...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646408&group_id=5470 From noreply@sourceforge.net Fri Dec 6 11:08:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 03:08:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-649122 ] marshal/pickle problem with True/False Message-ID: Bugs item #649122, was opened at 2002-12-05 20:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Shack Toms (shacktoms) Assigned to: Michael Hudson (mwh) Summary: marshal/pickle problem with True/False Initial Comment: It appears that True and False are special cases of integer 1 and 0 such that... >>> True is 1 0 >>> False is 0 0 After pickling or marshaling, however, this specialness is lost. >>> pickle.loads(pickle.dumps(True)) is 1 1 >>> pickle.loads(pickle.dumps(True)) is True 0 >>> pickle.loads(pickle.dumps(False)) is 0 1 >>> pickle.loads(pickle.dumps(False)) is False 0 In other words, True is unpickled as a non-special 1 and False is unpicked as a non-special 0. It appears that the problem, the bug, is that neither pickle nor marshal distinguishes between True/False and 1/0. >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> pickle.dumps(True) == pickle.dumps(1) 1 >>> pickle.dumps(False) == pickle.dumps(0) 1 >>> marshal.dumps(True) == marshal.dumps(1) 1 >>> marshal.dumps(False) == marshal.dumps(0) 1 My version info... Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Microsoft Windows 2000 5.00.2195 Service Pack 3 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-06 12:08 Message: Logged In: YES user_id=21627 For Python 2.3, this has been fixed, by making True and False instances of their own type, and by pickling an extra 0 before the integer value. For Python 2.2, this won't be fixed: This special-ness of True and False really is an implementation detail that should be be relied upon. Applications that absolutely need this property must implement custom getstate/setstate methods that restore boolean integers to their boolean-ness on setstate. That way, they also achieve portability to the released versions of Python 2.2, instead of relying on not-yet-and-perhaps-never released versions. ---------------------------------------------------------------------- Comment By: Shack Toms (shacktoms) Date: 2002-12-06 00:08 Message: Logged In: YES user_id=603293 True and False may be integers, but they are special in that they are Py_True and Py_False, internally. Why is this important? True and False are treated differently from 1 and 0 when converted to a variant by Mark Hammond's oleargs.cpp code, which specifically checks for Py_True and Py_False before checking for Integer-ness by calling PyInt_Check(). These values get converted to the VARIANT_BOOL type, with values 0xffff and 0. For this reason, it would be useful if their special "True" and "False" -ness could be preserved by pickling. >>> 1 == 1 1 >>> (1 == 1) is True 1 >>> (1 == 1) is 1 0 Because of the above, logical results get converted by Hammond's code to the correct VARIANT_BOOL types--but not after pickling. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-05 20:39 Message: Logged In: YES user_id=6656 I'm afraid you're a bit confused. In 2.2.x True and False are integers. They may not actually *be* the integers you get when you type 1 and 0, but they are still integers. If you try what you tried in a 2.3a0 build from CVS, you should see different answers. Applying identity (`is') to immutable objects is discouraged for exactly this sort of reason... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649122&group_id=5470 From noreply@sourceforge.net Fri Dec 6 15:13:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 07:13:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 10:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 03:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 05:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 05:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Fri Dec 6 15:33:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 07:33:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-534748 ] Removing _tkinter considered harmful Message-ID: Bugs item #534748, was opened at 2002-03-25 16:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul F. Dubois (dubois) Assigned to: A.M. Kuchling (akuchling) Summary: Removing _tkinter considered harmful Initial Comment: The Python build process now tries to import _tkinter and if it cannot removes it. There are two problems with this: a. It isn't correct. b. It removes the very thing required to understand why it won't import. (a) It isn't correct because it might import correctly later. If the user has, for example, installed tk / tcl in a place that is not in LD_LIBRARY_PATH, the import might fail during the Python build but succeed after the user sets this variable. Since the installer having it set is no guarantee the user will have it set, we aren't buying anything by verifying that the installer can import it. (b) If it won't import you just destroyed the evidence. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-06 15:33 Message: Logged In: YES user_id=6656 This should be fixed in revision 1.73.4.12 of setup.py. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-03 18:53 Message: Logged In: YES user_id=6656 Yes please! If you can look at #645383 at the same time, the more the merrier! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 18:51 Message: Logged In: YES user_id=11375 It didn't get ported to 2.2.2, either, or to the release22-maint branch. Should it be backported? (If not, this bug can be closed as "fixed in 2.3".) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-26 15:52 Message: Logged In: YES user_id=6656 The time machine strikes again; that's what happens in CVS Python (on the trunk; this didn't get ported to 221). ---------------------------------------------------------------------- Comment By: Paul F. Dubois (dubois) Date: 2002-04-26 15:38 Message: Logged In: YES user_id=5550 I now know that this is in Python's setup.py file. I suggest the offending file might be renamed rather than removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470 From noreply@sourceforge.net Fri Dec 6 17:19:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 09:19:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-06 12:19 Message: Logged In: YES user_id=31435 This also affects the C implementation of the datetime module. While it would be very nice to get it fixed before alpha 1, it doesn't need to be fixed before beta 1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 10:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 03:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 05:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 05:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Fri Dec 6 18:51:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Dec 2002 10:51:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-12-06 19:51 Message: Logged In: YES user_id=11105 Ok, here's a first outline in form of a patch. Probably the same should be done for staticmethods. All the tests pass on Windows except bz2 and bsddb which I didn't build, and test_descr failes because Modules/xxsubtype.c needs to be updated. If this looks ok, I'm willing to continue - it didn't take much longer than an hour so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-06 18:19 Message: Logged In: YES user_id=31435 This also affects the C implementation of the datetime module. While it would be very nice to get it fixed before alpha 1, it doesn't need to be fixed before beta 1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 16:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 09:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 11:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 11:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Sat Dec 7 08:19:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 00:19:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-649961 ] nturl2path.url2pathname() mishandles /// Message-ID: Bugs item #649961, was opened at 2002-12-07 01:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Tim Peters (tim_one) Summary: nturl2path.url2pathname() mishandles /// Initial Comment: On Windows, urllib.url2pathname('///path/to/file') returns r'\\path\to\file'. This path cannot be used in things like open() and os.access(). It should probably return r'\path\to\file'. In addition, '//localhost/path/to/file' is a special case that should become '\path\to\file'. I'll post this as a separate bug since it affects all file URIs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 From noreply@sourceforge.net Sat Dec 7 08:28:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 00:28:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-649962 ] All URL funcs mishandle file://localhost Message-ID: Bugs item #649962, was opened at 2002-12-07 01:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649962&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: All URL funcs mishandle file://localhost Initial Comment: Per RFC 1738 section 3.10: "A file URL takes the form: file:/// ... As a special case, can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted". In other words, regardless of what DNS or NetBIOS say about "localhost", it is always the local machine. Therefore, functions like urllib.url2pathname() and urllib.urlopen() and anything else that takes a URL argument should treat '///path/to/file' and '//localhost/path/to/file' identically, returning '/path/to/file' on Unix or '\path\to\file' on Windows, for example. (note separate bug report filed for url2pathname() mishandling '///path/to/file' on Windows) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649962&group_id=5470 From noreply@sourceforge.net Sat Dec 7 09:07:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 01:07:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-649967 ] urllib.urlopen('file:/...') uses FTP Message-ID: Bugs item #649967, was opened at 2002-12-07 02:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen('file:/...') uses FTP Initial Comment: urllib.urlopen(), when given a 'file' URL containing a host part, like 'file://somehost/path/to/file', treats it as if it were an 'ftp' URL. While RFC 1738 acknowledges that the access method for file URLs is unspecified, the assumption of FTP, even when a direct access method is available, is a poor design decision and is a possible security risk in applications that use urlopen(). When given a file URL, urlopen() should extract the portion following 'file:', convert a leading '//localhost/' to '///' (because localhost is a special case per RFC 1738; see other bug report on this topic), and use url2pathname() to try to convert this to an OS-specific path. The result can then be passed to open(). For example, on Windows, urlopen ('file://somehost/path/to/file') should return the result of open('\somehost\path\to\file', 'rb'). In situations where there is no convention for interpreting the host part of a URL as a component in an OS path, such as on Unix filesystems, an exception should be raised by url2pathname(), in my opinion. If urlopen() wants to try an alternate access method such as FTP, it should only do so if directed by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 From noreply@sourceforge.net Sat Dec 7 09:22:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 01:22:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 02:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply@sourceforge.net Sat Dec 7 09:24:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 01:24:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 02:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 02:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply@sourceforge.net Sat Dec 7 09:42:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 01:42:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-643227 ] __all__ not in RefMan index Message-ID: Bugs item #643227, was opened at 2002-11-24 15:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643227&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Raymond Hettinger (rhettinger) Summary: __all__ not in RefMan index Initial Comment: The export-control var __all__ is missing from the _ page of the Reference Manual index (as of 2.2.2 Oct 14 version). It is explained in the middle of section 6.12 Import Statement. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-07 04:42 Message: Logged In: YES user_id=80475 Fixed. See ref6.tex 1.57 and 1.47.4.5 Closing bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643227&group_id=5470 From noreply@sourceforge.net Sat Dec 7 10:16:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 02:16:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-643260 ] typo in Object/abstract.c : ternary_op Message-ID: Bugs item #643260, was opened at 2002-11-24 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643260&group_id=5470 Category: Python Interpreter Core >Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Cesar Douady (douady) Assigned to: Raymond Hettinger (rhettinger) Summary: typo in Object/abstract.c : ternary_op Initial Comment: in file Object/abstract.c, in function ternary_op, in the second test which computes slotw : if (w->ob_type != v->ob_type && mv != NULL && NEW_STYLE_NUMBER(w)) { ^^^ the test for mv is obviously a typo and should be replaced by mw : if (w->ob_type != v->ob_type && mw != NULL && NEW_STYLE_NUMBER(w)) { ^^^ This gives an inconsistent behavior of the ** operator which refuses to use the __rpow__ method when the first operand does not have a number methods. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-07 05:16 Message: Logged In: YES user_id=80475 Added testcase and fixed code: abstract.c 2.110 and 2.93.6.9 test_pow.py 1.16 and 1.13.14.1 Marking as fixed and closing bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643260&group_id=5470 From noreply@sourceforge.net Sat Dec 7 13:36:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 05:36:16 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-489899 ] bzip2 Message-ID: Feature Requests item #489899, was opened at 2001-12-06 17:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489899&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gábor BORGULYA (borgulya) Assigned to: Nobody/Anonymous (nobody) Summary: bzip2 Initial Comment: Hi ! I find the gzip module very useful, but I would use the bzip2 compression method instead, because it gives even more efficient compression. (For me ususally about extra 15%.) So, I would welcome a bzip2 module! http://sources.redhat.com/bzip2/index.html Yours, Gabor ---------------------------------------------------------------------- >Comment By: Gábor BORGULYA (borgulya) Date: 2002-12-07 14:36 Message: Logged In: YES user_id=131307 Yes, thank you! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-08 00:30 Message: Logged In: YES user_id=89016 A module named bz2 is now in CVS. Can you try this out? If it does what you want, I think we can close the feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489899&group_id=5470 From noreply@sourceforge.net Sat Dec 7 15:50:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 07:50:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-649961 ] nturl2path.url2pathname() mishandles /// Message-ID: Bugs item #649961, was opened at 2002-12-07 03:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) >Assigned to: Nobody/Anonymous (nobody) Summary: nturl2path.url2pathname() mishandles /// Initial Comment: On Windows, urllib.url2pathname('///path/to/file') returns r'\\path\to\file'. This path cannot be used in things like open() and os.access(). It should probably return r'\path\to\file'. In addition, '//localhost/path/to/file' is a special case that should become '\path\to\file'. I'll post this as a separate bug since it affects all file URIs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 From noreply@sourceforge.net Sat Dec 7 18:36:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 10:36:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 10:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 04:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 13:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 02:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 01:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 14:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 13:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 23:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 11:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 21:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sat Dec 7 19:40:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 11:40:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 20:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 19:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 22:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sat Dec 7 19:57:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Dec 2002 11:57:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 11:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 11:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 10:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 04:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 13:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 02:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 01:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 14:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 13:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 23:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 11:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-02 21:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-01 20:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sun Dec 8 09:03:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 01:03:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-649967 ] urllib.urlopen('file:/...') uses FTP Message-ID: Bugs item #649967, was opened at 2002-12-07 10:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen('file:/...') uses FTP Initial Comment: urllib.urlopen(), when given a 'file' URL containing a host part, like 'file://somehost/path/to/file', treats it as if it were an 'ftp' URL. While RFC 1738 acknowledges that the access method for file URLs is unspecified, the assumption of FTP, even when a direct access method is available, is a poor design decision and is a possible security risk in applications that use urlopen(). When given a file URL, urlopen() should extract the portion following 'file:', convert a leading '//localhost/' to '///' (because localhost is a special case per RFC 1738; see other bug report on this topic), and use url2pathname() to try to convert this to an OS-specific path. The result can then be passed to open(). For example, on Windows, urlopen ('file://somehost/path/to/file') should return the result of open('\somehost\path\to\file', 'rb'). In situations where there is no convention for interpreting the host part of a URL as a component in an OS path, such as on Unix filesystems, an exception should be raised by url2pathname(), in my opinion. If urlopen() wants to try an alternate access method such as FTP, it should only do so if directed by the caller. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 10:03 Message: Logged In: YES user_id=21627 This is not a bug; it is documented behaviour: see http://python.org/doc/current/lib/module-urllib.html To override this behaviour, use urllib2, and inherit from FileHandler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 From noreply@sourceforge.net Sun Dec 8 12:37:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 04:37:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 >Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 13:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 20:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 20:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 19:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 22:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sun Dec 8 13:30:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 05:30:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 14:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 13:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 20:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 20:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 19:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 22:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Sun Dec 8 15:04:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 07:04:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-650441 ] email test external dependencies Message-ID: Bugs item #650441, was opened at 2002-12-08 10:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650441&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email test external dependencies Initial Comment: The email package test depends on audiotest.au which comes as part of Python's test suite. This can fail for standalone email on some systems that don't package the test suite with their "non-devel" Python packages. email/test/data should include a simple, small audio file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650441&group_id=5470 From noreply@sourceforge.net Sun Dec 8 17:07:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 09:07:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-648658 ] xmlrpc can't do proxied HTTP Message-ID: Bugs item #648658, was opened at 2002-12-04 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648658&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Bumgarner (bbum) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpc can't do proxied HTTP Initial Comment: The current xmlrpclib can't communicate through a proxy server. In particular, the two Transport classes contained within xmlrpclib use httplib directly and, as such, do not support the proxy handling as offered by urllib. Or so it seems. I'm in dire need of support for proxies in xmlrpclib and will be investigating creating a custom Transport class that uses urllib as opposed to httplib to gain support for proxies. Assuming success, I'll post the new transport class here. In the interim, I figured I would log a bug in case anyone else is interested in working on the problem (or already has a solution :). b.bum bbum@mac.com ---------------------------------------------------------------------- >Comment By: Bill Bumgarner (bbum) Date: 2002-12-08 12:07 Message: Logged In: YES user_id=103811 As discussed on python-dev and with Fredrick Lundh, I created an HTTPTransport class that uses urllib2 to implement the HTTP transport. It works around a bug in urllib2 [handler ordering] and augments the request dispatch found in the Transport class. I'm using it in a production context and have tested it fairly heavily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648658&group_id=5470 From noreply@sourceforge.net Sun Dec 8 17:19:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 09:19:15 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-648658 ] xmlrpc can't do proxied HTTP Message-ID: Feature Requests item #648658, was opened at 2002-12-04 23:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=648658&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Bumgarner (bbum) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpc can't do proxied HTTP Initial Comment: The current xmlrpclib can't communicate through a proxy server. In particular, the two Transport classes contained within xmlrpclib use httplib directly and, as such, do not support the proxy handling as offered by urllib. Or so it seems. I'm in dire need of support for proxies in xmlrpclib and will be investigating creating a custom Transport class that uses urllib as opposed to httplib to gain support for proxies. Assuming success, I'll post the new transport class here. In the interim, I figured I would log a bug in case anyone else is interested in working on the problem (or already has a solution :). b.bum bbum@mac.com ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2002-12-08 18:07 Message: Logged In: YES user_id=103811 As discussed on python-dev and with Fredrick Lundh, I created an HTTPTransport class that uses urllib2 to implement the HTTP transport. It works around a bug in urllib2 [handler ordering] and augments the request dispatch found in the Transport class. I'm using it in a production context and have tested it fairly heavily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=648658&group_id=5470 From noreply@sourceforge.net Sun Dec 8 22:22:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 14:22:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-649967 ] urllib.urlopen('file:/...') uses FTP Message-ID: Bugs item #649967, was opened at 2002-12-07 02:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen('file:/...') uses FTP Initial Comment: urllib.urlopen(), when given a 'file' URL containing a host part, like 'file://somehost/path/to/file', treats it as if it were an 'ftp' URL. While RFC 1738 acknowledges that the access method for file URLs is unspecified, the assumption of FTP, even when a direct access method is available, is a poor design decision and is a possible security risk in applications that use urlopen(). When given a file URL, urlopen() should extract the portion following 'file:', convert a leading '//localhost/' to '///' (because localhost is a special case per RFC 1738; see other bug report on this topic), and use url2pathname() to try to convert this to an OS-specific path. The result can then be passed to open(). For example, on Windows, urlopen ('file://somehost/path/to/file') should return the result of open('\somehost\path\to\file', 'rb'). In situations where there is no convention for interpreting the host part of a URL as a component in an OS path, such as on Unix filesystems, an exception should be raised by url2pathname(), in my opinion. If urlopen() wants to try an alternate access method such as FTP, it should only do so if directed by the caller. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2002-12-08 15:22 Message: Logged In: YES user_id=371366 If you document it, it's not a bug? The docs say that the fallback on FTP is "for backward compatibility" ... backward compatibility with what? The fact that it's a possible security risk should at least be documented. An application on a machine behind a firewall might not be expecting 'file' URLs to result in hitting the FTP servers of that machine or its neighbors. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 02:03 Message: Logged In: YES user_id=21627 This is not a bug; it is documented behaviour: see http://python.org/doc/current/lib/module-urllib.html To override this behaviour, use urllib2, and inherit from FileHandler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 From noreply@sourceforge.net Mon Dec 9 00:24:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 16:24:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-649967 ] urllib.urlopen('file:/...') uses FTP Message-ID: Bugs item #649967, was opened at 2002-12-07 10:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen('file:/...') uses FTP Initial Comment: urllib.urlopen(), when given a 'file' URL containing a host part, like 'file://somehost/path/to/file', treats it as if it were an 'ftp' URL. While RFC 1738 acknowledges that the access method for file URLs is unspecified, the assumption of FTP, even when a direct access method is available, is a poor design decision and is a possible security risk in applications that use urlopen(). When given a file URL, urlopen() should extract the portion following 'file:', convert a leading '//localhost/' to '///' (because localhost is a special case per RFC 1738; see other bug report on this topic), and use url2pathname() to try to convert this to an OS-specific path. The result can then be passed to open(). For example, on Windows, urlopen ('file://somehost/path/to/file') should return the result of open('\somehost\path\to\file', 'rb'). In situations where there is no convention for interpreting the host part of a URL as a component in an OS path, such as on Unix filesystems, an exception should be raised by url2pathname(), in my opinion. If urlopen() wants to try an alternate access method such as FTP, it should only do so if directed by the caller. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-09 01:24 Message: Logged In: YES user_id=21627 Backwards compatibility with previous releases. There is no way to change this, except for a full PEP procedure, with deprecation, and so on. This would be different if there was a *clear* bug, like a interpreter crash, a clear deviation of documented behaviour, or a clear deviation from relevant standards. I fail to see the security risk. If an application uses urllib, various network activity can happen. You seem to be saying that there is a security issue because the application author is not expecting network activity to happen. However a) there won't be any disclosure of unwanted information, and b) the documentation of urllib is full of references to network activity, so anybody using urllib should really know. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-08 23:22 Message: Logged In: YES user_id=371366 If you document it, it's not a bug? The docs say that the fallback on FTP is "for backward compatibility" ... backward compatibility with what? The fact that it's a possible security risk should at least be documented. An application on a machine behind a firewall might not be expecting 'file' URLs to result in hitting the FTP servers of that machine or its neighbors. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 10:03 Message: Logged In: YES user_id=21627 This is not a bug; it is documented behaviour: see http://python.org/doc/current/lib/module-urllib.html To override this behaviour, use urllib2, and inherit from FileHandler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649967&group_id=5470 From noreply@sourceforge.net Mon Dec 9 02:11:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 18:11:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-08 17:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Mon Dec 9 05:12:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Dec 2002 21:12:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) >Assigned to: Guido van Rossum (gvanrossum) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-09 00:12 Message: Logged In: YES user_id=31435 Guido, does this patch match your and Fred's intent? I want to get this fixed, as it pops up a dozen times in the datetime project. Feel free to do a braindump on me tomorrow and make it my headache. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 13:51 Message: Logged In: YES user_id=11105 Ok, here's a first outline in form of a patch. Probably the same should be done for staticmethods. All the tests pass on Windows except bz2 and bsddb which I didn't build, and test_descr failes because Modules/xxsubtype.c needs to be updated. If this looks ok, I'm willing to continue - it didn't take much longer than an hour so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-06 12:19 Message: Logged In: YES user_id=31435 This also affects the C implementation of the datetime module. While it would be very nice to get it fixed before alpha 1, it doesn't need to be fixed before beta 1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 10:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 03:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 05:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 05:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Mon Dec 9 08:22:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 00:22:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-650739 ] Binary pickle format depends on marshal Message-ID: Bugs item #650739, was opened at 2002-12-09 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Binary pickle format depends on marshal Initial Comment: The documentation of the pickle package (section 3.14.1) says "The pickle serialization format is guaranteed to be backwards compatible across Python releases." While this is easy to verify for the non-binary format, the binary format calls marshal.dumps and marshal.loads in quite a few places, and is thus subject to the statement in the same paragraph that "The marshal serialization format is not guaranteed to be portable across Python versions." It appears that mdumps and mloads are only used for converting integers to and from binary format. I suggest that instead of invoking mdumps and mloads, the pickle code include its own copies of these two simple algorithms. I haven't looked at cPickle, so I don't know whether it calls the marshal code, or whether it implements the algorithms itself. If the former, I suggest changing it too to the latter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 From noreply@sourceforge.net Mon Dec 9 13:48:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 05:48:25 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-489899 ] bzip2 Message-ID: Feature Requests item #489899, was opened at 2001-12-06 17:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489899&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gábor BORGULYA (borgulya) Assigned to: Nobody/Anonymous (nobody) Summary: bzip2 Initial Comment: Hi ! I find the gzip module very useful, but I would use the bzip2 compression method instead, because it gives even more efficient compression. (For me ususally about extra 15%.) So, I would welcome a bzip2 module! http://sources.redhat.com/bzip2/index.html Yours, Gabor ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-12-09 14:48 Message: Logged In: YES user_id=89016 OK, closing the bug report as fixed. ---------------------------------------------------------------------- Comment By: Gábor BORGULYA (borgulya) Date: 2002-12-07 14:36 Message: Logged In: YES user_id=131307 Yes, thank you! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-11-08 00:30 Message: Logged In: YES user_id=89016 A module named bz2 is now in CVS. Can you try this out? If it does what you want, I think we can close the feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=489899&group_id=5470 From noreply@sourceforge.net Mon Dec 9 16:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 08:24:01 -0800 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: Pending >Resolution: Fixed 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-12-09 11:24 Message: Logged In: YES user_id=14422 Hopefully fixed in rev 1.19 of textwrap.py. Not in test suite yet, so I'm leaving this one "pending". ---------------------------------------------------------------------- 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 Mon Dec 9 16:27:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 08:27:37 -0800 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: Closed >Resolution: Fixed 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: Greg Ward (gward) Date: 2002-12-09 11:27 Message: Logged In: YES user_id=14422 Fixed in rev 1.20 of textwrap.py; tested in rev 1.17 of test/test_textwrap.py. ---------------------------------------------------------------------- Comment By: R. David Murray (rdmurray) Date: 2002-10-14 20: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 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 Mon Dec 9 16:33:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 08:33:05 -0800 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: Closed Resolution: Fixed 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-12-09 11:33 Message: Logged In: YES user_id=14422 OK, tested in rev 1.18 of test/test_textwrap.py. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-12-09 11:24 Message: Logged In: YES user_id=14422 Hopefully fixed in rev 1.19 of textwrap.py. Not in test suite yet, so I'm leaving this one "pending". ---------------------------------------------------------------------- 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 Mon Dec 9 16:53:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 08:53:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-650739 ] Binary pickle format depends on marshal Message-ID: Bugs item #650739, was opened at 2002-12-09 03:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) >Assigned to: Tim Peters (tim_one) Summary: Binary pickle format depends on marshal Initial Comment: The documentation of the pickle package (section 3.14.1) says "The pickle serialization format is guaranteed to be backwards compatible across Python releases." While this is easy to verify for the non-binary format, the binary format calls marshal.dumps and marshal.loads in quite a few places, and is thus subject to the statement in the same paragraph that "The marshal serialization format is not guaranteed to be portable across Python versions." It appears that mdumps and mloads are only used for converting integers to and from binary format. I suggest that instead of invoking mdumps and mloads, the pickle code include its own copies of these two simple algorithms. I haven't looked at cPickle, so I don't know whether it calls the marshal code, or whether it implements the algorithms itself. If the former, I suggest changing it too to the latter. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-09 11:53 Message: Logged In: YES user_id=31435 Closing this as Invalid. So long as the doc's promises are kept, it doesn't matter how the implementation accomplishes it. If the marshal format changes in an incompatible way someday, then pickle will have to stop using marshal routines. Changing that beforehand isn't needed or helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 From noreply@sourceforge.net Mon Dec 9 17:10:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 09:10:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-650739 ] Binary pickle format depends on marshal Message-ID: Bugs item #650739, was opened at 2002-12-09 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 Category: Python Library >Group: Python 2.2.2 >Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Tim Peters (tim_one) Summary: Binary pickle format depends on marshal Initial Comment: The documentation of the pickle package (section 3.14.1) says "The pickle serialization format is guaranteed to be backwards compatible across Python releases." While this is easy to verify for the non-binary format, the binary format calls marshal.dumps and marshal.loads in quite a few places, and is thus subject to the statement in the same paragraph that "The marshal serialization format is not guaranteed to be portable across Python versions." It appears that mdumps and mloads are only used for converting integers to and from binary format. I suggest that instead of invoking mdumps and mloads, the pickle code include its own copies of these two simple algorithms. I haven't looked at cPickle, so I don't know whether it calls the marshal code, or whether it implements the algorithms itself. If the former, I suggest changing it too to the latter. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-12-09 09:10 Message: Logged In: YES user_id=8861 There is currently no documentation anywhere in the code to alert the maintainer of the marshal package to the fact that pickle has a design dependency on it. On the contrary, the comment in marshal.c says "This is intended for writing and reading compiled Python code only." Hidden dependencies of this kind are an invitation to future obscure problems. If the dependency is not removed, it should at least be documented. If the code is not changed, I strongly advocate adding the following comment to marshal.c: "Note that the pickle package (pickle.py) uses the dump and load methods from this package for writing and reading integer values. If these methods are ever changed, their old implementation must be copied to pickle.py." I still think it would make a lot more sense to simply duplicate the code. We're talking about 10-20 lines of Python code here, added to nearly 1,000 lines of code in pickle.py. And I would note that cPickle.c *already* duplicates these algorithms rather than using the implementation in marshal. Would the Python team be willing to consider making this change if I wrote and tested the code myself? If so, is there a procedure I should follow for submitting the code, or is posting the code as a follow-up comment here sufficient? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 08:53 Message: Logged In: YES user_id=31435 Closing this as Invalid. So long as the doc's promises are kept, it doesn't matter how the implementation accomplishes it. If the marshal format changes in an incompatible way someday, then pickle will have to stop using marshal routines. Changing that beforehand isn't needed or helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 From noreply@sourceforge.net Mon Dec 9 17:50:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 09:50:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-650739 ] Binary pickle format depends on marshal Message-ID: Bugs item #650739, was opened at 2002-12-09 03:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Tim Peters (tim_one) Summary: Binary pickle format depends on marshal Initial Comment: The documentation of the pickle package (section 3.14.1) says "The pickle serialization format is guaranteed to be backwards compatible across Python releases." While this is easy to verify for the non-binary format, the binary format calls marshal.dumps and marshal.loads in quite a few places, and is thus subject to the statement in the same paragraph that "The marshal serialization format is not guaranteed to be portable across Python versions." It appears that mdumps and mloads are only used for converting integers to and from binary format. I suggest that instead of invoking mdumps and mloads, the pickle code include its own copies of these two simple algorithms. I haven't looked at cPickle, so I don't know whether it calls the marshal code, or whether it implements the algorithms itself. If the former, I suggest changing it too to the latter. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-09 12:50 Message: Logged In: YES user_id=31435 There isn't a bug here, just your fear of a potential bug someday. The few people who touch marshal are acutely aware of the issues here already -- that's why your fears haven't materialized in the last decade of living dangerously . If you want to add comments to the module, you can upload a patch to the patch manager here, and I expect someone will apply it. Code duplication is a clear and present evil, and would not be accepted. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-09 12:10 Message: Logged In: YES user_id=8861 There is currently no documentation anywhere in the code to alert the maintainer of the marshal package to the fact that pickle has a design dependency on it. On the contrary, the comment in marshal.c says "This is intended for writing and reading compiled Python code only." Hidden dependencies of this kind are an invitation to future obscure problems. If the dependency is not removed, it should at least be documented. If the code is not changed, I strongly advocate adding the following comment to marshal.c: "Note that the pickle package (pickle.py) uses the dump and load methods from this package for writing and reading integer values. If these methods are ever changed, their old implementation must be copied to pickle.py." I still think it would make a lot more sense to simply duplicate the code. We're talking about 10-20 lines of Python code here, added to nearly 1,000 lines of code in pickle.py. And I would note that cPickle.c *already* duplicates these algorithms rather than using the implementation in marshal. Would the Python team be willing to consider making this change if I wrote and tested the code myself? If so, is there a procedure I should follow for submitting the code, or is posting the code as a follow-up comment here sufficient? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 11:53 Message: Logged In: YES user_id=31435 Closing this as Invalid. So long as the doc's promises are kept, it doesn't matter how the implementation accomplishes it. If the marshal format changes in an incompatible way someday, then pickle will have to stop using marshal routines. Changing that beforehand isn't needed or helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 From noreply@sourceforge.net Mon Dec 9 18:05:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 10:05:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-650739 ] Binary pickle format depends on marshal Message-ID: Bugs item #650739, was opened at 2002-12-09 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Tim Peters (tim_one) Summary: Binary pickle format depends on marshal Initial Comment: The documentation of the pickle package (section 3.14.1) says "The pickle serialization format is guaranteed to be backwards compatible across Python releases." While this is easy to verify for the non-binary format, the binary format calls marshal.dumps and marshal.loads in quite a few places, and is thus subject to the statement in the same paragraph that "The marshal serialization format is not guaranteed to be portable across Python versions." It appears that mdumps and mloads are only used for converting integers to and from binary format. I suggest that instead of invoking mdumps and mloads, the pickle code include its own copies of these two simple algorithms. I haven't looked at cPickle, so I don't know whether it calls the marshal code, or whether it implements the algorithms itself. If the former, I suggest changing it too to the latter. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2002-12-09 10:05 Message: Logged In: YES user_id=8861 Yes, code duplication is an evil. So are undocumented dependencies. In this case, we simply have different opinions as to which evil is lesser. :-) I'm willing to let the bug be closed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 09:50 Message: Logged In: YES user_id=31435 There isn't a bug here, just your fear of a potential bug someday. The few people who touch marshal are acutely aware of the issues here already -- that's why your fears haven't materialized in the last decade of living dangerously . If you want to add comments to the module, you can upload a patch to the patch manager here, and I expect someone will apply it. Code duplication is a clear and present evil, and would not be accepted. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-09 09:10 Message: Logged In: YES user_id=8861 There is currently no documentation anywhere in the code to alert the maintainer of the marshal package to the fact that pickle has a design dependency on it. On the contrary, the comment in marshal.c says "This is intended for writing and reading compiled Python code only." Hidden dependencies of this kind are an invitation to future obscure problems. If the dependency is not removed, it should at least be documented. If the code is not changed, I strongly advocate adding the following comment to marshal.c: "Note that the pickle package (pickle.py) uses the dump and load methods from this package for writing and reading integer values. If these methods are ever changed, their old implementation must be copied to pickle.py." I still think it would make a lot more sense to simply duplicate the code. We're talking about 10-20 lines of Python code here, added to nearly 1,000 lines of code in pickle.py. And I would note that cPickle.c *already* duplicates these algorithms rather than using the implementation in marshal. Would the Python team be willing to consider making this change if I wrote and tested the code myself? If so, is there a procedure I should follow for submitting the code, or is posting the code as a follow-up comment here sufficient? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 08:53 Message: Logged In: YES user_id=31435 Closing this as Invalid. So long as the doc's promises are kept, it doesn't matter how the implementation accomplishes it. If the marshal format changes in an incompatible way someday, then pickle will have to stop using marshal routines. Changing that beforehand isn't needed or helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 From noreply@sourceforge.net Mon Dec 9 18:30:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 10:30:03 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-644940 ] Support file path concat with "/" Message-ID: Feature Requests item #644940, was opened at 2002-11-27 21:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark VanTassel (markvantassel) Assigned to: Nobody/Anonymous (nobody) >Summary: Support file path concat with "/" Initial Comment: A very useful feature is to overload the "/" operator for strings to support path concatenation - that is, to concat the left and right arguments in such a way that there is exactly one slash between them, regardless of which argument(s) did or didn't include slashes: dir = "/this/that" file = "whatever.py" print dir / file #prints "/this/that/whatever.py" It seems silly, but when you're not 100% in control of things (such as when reading paths from config files, user input, etc), it's great to be sure that the right thing will happen without writing/testing a lot of icky code. And even when you are 100% in control, it's nice to not have to worry about it so much. This doesn't seem to conflict with any existing usage or syntax, so I don't think it can possibly break any existing behaviour (except, of course, those who were counting on having an exception thrown!) I've already coded this as a minor tweak to the Python 2.2.2 release, and I'd be happy to share the fix with the powers that be, if there's general concensus that this is a good thing. Feedback is solicited and appreciated (this is my first foray into open-source development, so be gentle!) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-12-09 19:30 Message: Logged In: YES user_id=89016 IMHO implementing str / str as a duplicate of os.path.join blurs what a string is. The meaning of a type should be tied to the type and not to various sets of operators (for + a str instance is treated as a string, for / as a filename). And if we add /, where should we stop? str.open(), str.exists(), str.stat() etc.? If we duplicate every function in os.path we might get name clashes. IMHO string and filename APIs should be kept separate. So the clearer solution would to be implement a separate filename class. Whether this is a subclass of str or not is IMHO unclear. What about Unicode filenames? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 19:24 Message: Logged In: YES user_id=21627 Please notice that there is an established function in Python that has the same effect: os.path.join: >>> dir = "/this/that" >>> file = "whatever.py" >>> import os >>> print os.path.join(dir,file) /this/that/whatever.py There is, in general, reluctance to add new syntax to Python if you can achieve the same effect with a function - in particular if the function has been there for a long time. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 21:00 Message: Logged In: YES user_id=33168 How often do you really need this? Is it that bad/hard to use os.path.join? There are always problems with adding new features which overload existing operations, like using "/". It's true that it would raise an exception today, so could be acceptable to implement str / str. However, unless this is for a very common task, is it worth it? Using / to join path components is not obvious to me. I doubt it would be generally obvious. Would it be confusing? There is the cost of not being able to use / for something possibly more meaningful and more common if this were implemented. ---------------------------------------------------------------------- Comment By: Mark VanTassel (markvantassel) Date: 2002-11-29 14:02 Message: Logged In: YES user_id=658048 Having used a C++ string class with overloaded "/", I can assure you it's quite useful. Aside from the executable being about 100 bytes larger, I can't see how it hurts anything. The righthandside absolute path (assuming you mean with a non-empty leftside path) is a semantic problem. You could reasonably say that if the right side starts with a slash, ignore the left side. Similarly, if the rightside starts with "X:" (under windows), ignore the left side. The Mac version could certainly insert ":" chars instead of slashes. Note, though, that the "/" operator isn't intended to solve all the worlds problems - if you have quirky path-usage rules, you'll probably have to implement them yourself regardless. This is just to make the relatively simple stuff (hopefully the 80% case) drop-dead simple and avoid strange errors when the user improperly specifies a directory (or a file) in a config file or whatever. URLs are a more intriguing issue - they were far less important the first time I implemented this. I suppose a subclass would be best. And while OS-specific flavors might be nice add-ons (for those rare cases when a Mac is concatenating paths meant for evaluation on a windows machine, etc), I strongly believe that the "default" behaviour should be appropriate for the current OS, thereby promoting code portability. Question: Would it be too ugly (or too difficult) to have a prefix character (analogous to the "r" for raw strings) to specify that a literal string is of one of the above-suggested subtypes? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-29 10:46 Message: Logged In: YES user_id=45365 Apart from the question of whether pathname concatenation is important enough to add a special operator on the string type for (I think not), there are lots of boundary issues with your proposal. For instance, how about a righthandside absolute path? How about two paths with C: style disks in them on Windows? How about Macintosh pathnames (colon-separated, with relative paths starting with a colon)? Or, why does it concatenate pathnames in the first place, and not URLs (makes a difference on Mac)? If you want to continue down this trail I would suggest the first step is to subclass strings. You can then have separate subclasses for Windows paths, Unix paths, URLs, Mac paths, etc. ---------------------------------------------------------------------- Comment By: Mark VanTassel (markvantassel) Date: 2002-11-27 21:49 Message: Logged In: YES user_id=658048 P.S. There are a few loose ends for discussion: 1) What to do with empty strings? My current implementation doesn't do anything special, so dir/"" ends with a slash, ""/file starts with a slash, and ""/"" is a slash. If someone thinks different behaviour would be better, I'm open to alternatives. 2) What about back slashes on Windows (my native platform, actually)? My version removes trailing slashes and backslashes from the 1st arg, and removes leading slashes and backslashes from the 2nd ard, and then puts a backslash between them... but again I'm open to alternatives. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=644940&group_id=5470 From noreply@sourceforge.net Mon Dec 9 18:31:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 10:31:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) >Assigned to: Tim Peters (tim_one) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-09 13:31 Message: Logged In: YES user_id=6380 >From a brief skim of the patch, it looks like this is indeed what's needed. I guess Tim can check it in (with my helpp, I'm sitting right behind him). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 00:12 Message: Logged In: YES user_id=31435 Guido, does this patch match your and Fred's intent? I want to get this fixed, as it pops up a dozen times in the datetime project. Feel free to do a braindump on me tomorrow and make it my headache. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 13:51 Message: Logged In: YES user_id=11105 Ok, here's a first outline in form of a patch. Probably the same should be done for staticmethods. All the tests pass on Windows except bz2 and bsddb which I didn't build, and test_descr failes because Modules/xxsubtype.c needs to be updated. If this looks ok, I'm willing to continue - it didn't take much longer than an hour so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-06 12:19 Message: Logged In: YES user_id=31435 This also affects the C implementation of the datetime module. While it would be very nice to get it fixed before alpha 1, it doesn't need to be fixed before beta 1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 10:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 03:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 05:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 05:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Mon Dec 9 18:39:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 10:39:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Tim Peters (tim_one) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-09 13:39 Message: Logged In: YES user_id=6380 NB a small patch to test_descr is needed, as it currently contains a test that asserts the old behavior: *** test_descr.py 27 Nov 2002 16:29:26 -0000 1.168 --- test_descr.py 9 Dec 2002 18:38:20 -0000 *************** *** 1464,1475 **** a = (1, 2, 3) d = {'abc': 123} x, a1, d1 = spam.spamlist.classmeth(*a, **d) ! veris(x, None) ! vereq((spam.spamlist,) + a, a1) vereq(d, d1) x, a1, d1 = spam.spamlist().classmeth(*a, **d) ! veris(x, None) ! vereq((spam.spamlist,) + a, a1) vereq(d, d1) def staticmethods(): --- 1464,1475 ---- a = (1, 2, 3) d = {'abc': 123} x, a1, d1 = spam.spamlist.classmeth(*a, **d) ! veris(x, spam.spamlist) ! vereq(a, a1) vereq(d, d1) x, a1, d1 = spam.spamlist().classmeth(*a, **d) ! veris(x, spam.spamlist) ! vereq(a, a1) vereq(d, d1) def staticmethods(): ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-09 13:31 Message: Logged In: YES user_id=6380 >From a brief skim of the patch, it looks like this is indeed what's needed. I guess Tim can check it in (with my helpp, I'm sitting right behind him). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 00:12 Message: Logged In: YES user_id=31435 Guido, does this patch match your and Fred's intent? I want to get this fixed, as it pops up a dozen times in the datetime project. Feel free to do a braindump on me tomorrow and make it my headache. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 13:51 Message: Logged In: YES user_id=11105 Ok, here's a first outline in form of a patch. Probably the same should be done for staticmethods. All the tests pass on Windows except bz2 and bsddb which I didn't build, and test_descr failes because Modules/xxsubtype.c needs to be updated. If this looks ok, I'm willing to continue - it didn't take much longer than an hour so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-06 12:19 Message: Logged In: YES user_id=31435 This also affects the C implementation of the datetime module. While it would be very nice to get it fixed before alpha 1, it doesn't need to be fixed before beta 1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 10:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 03:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 05:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 05:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Mon Dec 9 19:02:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 11:02:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-650739 ] Binary pickle format depends on marshal Message-ID: Bugs item #650739, was opened at 2002-12-09 03:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 Category: Python Library >Group: Not a Bug Status: Closed >Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Tim Peters (tim_one) Summary: Binary pickle format depends on marshal Initial Comment: The documentation of the pickle package (section 3.14.1) says "The pickle serialization format is guaranteed to be backwards compatible across Python releases." While this is easy to verify for the non-binary format, the binary format calls marshal.dumps and marshal.loads in quite a few places, and is thus subject to the statement in the same paragraph that "The marshal serialization format is not guaranteed to be portable across Python versions." It appears that mdumps and mloads are only used for converting integers to and from binary format. I suggest that instead of invoking mdumps and mloads, the pickle code include its own copies of these two simple algorithms. I haven't looked at cPickle, so I don't know whether it calls the marshal code, or whether it implements the algorithms itself. If the former, I suggest changing it too to the latter. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-09 13:05 Message: Logged In: YES user_id=8861 Yes, code duplication is an evil. So are undocumented dependencies. In this case, we simply have different opinions as to which evil is lesser. :-) I'm willing to let the bug be closed. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 12:50 Message: Logged In: YES user_id=31435 There isn't a bug here, just your fear of a potential bug someday. The few people who touch marshal are acutely aware of the issues here already -- that's why your fears haven't materialized in the last decade of living dangerously . If you want to add comments to the module, you can upload a patch to the patch manager here, and I expect someone will apply it. Code duplication is a clear and present evil, and would not be accepted. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-09 12:10 Message: Logged In: YES user_id=8861 There is currently no documentation anywhere in the code to alert the maintainer of the marshal package to the fact that pickle has a design dependency on it. On the contrary, the comment in marshal.c says "This is intended for writing and reading compiled Python code only." Hidden dependencies of this kind are an invitation to future obscure problems. If the dependency is not removed, it should at least be documented. If the code is not changed, I strongly advocate adding the following comment to marshal.c: "Note that the pickle package (pickle.py) uses the dump and load methods from this package for writing and reading integer values. If these methods are ever changed, their old implementation must be copied to pickle.py." I still think it would make a lot more sense to simply duplicate the code. We're talking about 10-20 lines of Python code here, added to nearly 1,000 lines of code in pickle.py. And I would note that cPickle.c *already* duplicates these algorithms rather than using the implementation in marshal. Would the Python team be willing to consider making this change if I wrote and tested the code myself? If so, is there a procedure I should follow for submitting the code, or is posting the code as a follow-up comment here sufficient? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 11:53 Message: Logged In: YES user_id=31435 Closing this as Invalid. So long as the doc's promises are kept, it doesn't matter how the implementation accomplishes it. If the marshal format changes in an incompatible way someday, then pickle will have to stop using marshal routines. Changing that beforehand isn't needed or helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650739&group_id=5470 From noreply@sourceforge.net Mon Dec 9 22:00:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 14:00:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-651124 ] pydoc ignores $PAGER if TERM=='dumb' Message-ID: Bugs item #651124, was opened at 2002-12-09 22:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc ignores $PAGER if TERM=='dumb' Initial Comment: bug: pydoc ignores $PAGER environment variable if TERM=='dumb' symptom: when using pydoc as a keyword helper system (set keywordprg) pydoc scrolls all over its contents without paging, since gvim sets its terminal type to 'dumb' for shell escape. Fix: patch included. function getpager() rearranged. Inyeol Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 From noreply@sourceforge.net Mon Dec 9 22:06:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 14:06:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-651124 ] pydoc ignores $PAGER if TERM=='dumb' Message-ID: Bugs item #651124, was opened at 2002-12-09 22:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc ignores $PAGER if TERM=='dumb' Initial Comment: bug: pydoc ignores $PAGER environment variable if TERM=='dumb' symptom: when using pydoc as a keyword helper system (set keywordprg) pydoc scrolls all over its contents without paging, since gvim sets its terminal type to 'dumb' for shell escape. Fix: patch included. function getpager() rearranged. Inyeol Lee ---------------------------------------------------------------------- >Comment By: Inyeol Lee (inyeol) Date: 2002-12-09 22:06 Message: Logged In: YES user_id=595280 description on symptom above is for gvim. it was not clear there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 From noreply@sourceforge.net Mon Dec 9 22:49:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 14:49:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-651149 ] Review libshelve.tex when possible Message-ID: Bugs item #651149, was opened at 2002-12-09 16:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651149&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Review libshelve.tex when possible Initial Comment: I added a significant amount of text to libshelve.tex. None of the classes the shelve library exports were described. I also added some stuff about the new binary flag. Probably worth a look from a TeX perspective when you get a chance, but not terribly high priority. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651149&group_id=5470 From noreply@sourceforge.net Mon Dec 9 22:58:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 14:58:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation Message-ID: Bugs item #548651, was opened at 2002-04-25 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Tim Peters (tim_one) Summary: Fix the METH_CLASS implementation Initial Comment: The devel-docs about METH_CLASS: The method will be passed the type object as the first parameter rather than an instance of the type. This is used to create class methods, similar to what is created when using the classmethod() built-in function. New in version 2.3. The code does not do it in this way. The first parameter the function receives is NULL, the type object goes together with the remaining arguments in the second parameter (which is a tuple). See the thread with subject 'METH_CLASS' on python-dev at 2002-04-25, Guido agreed that this should be fixed. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-09 17:58 Message: Logged In: YES user_id=31435 Thanks, fellows! The changes were checked in, Include/descrobject.h; new revision: 2.12 Lib/test/test_descr.py; new revision: 1.169 Objects/descrobject.c; new revision: 2.32 Objects/dictobject.c; new revision: 2.136 Objects/typeobject.c; new revision: 2.197 I still need to fix the sandbox datetime code accordingly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-09 13:39 Message: Logged In: YES user_id=6380 NB a small patch to test_descr is needed, as it currently contains a test that asserts the old behavior: *** test_descr.py 27 Nov 2002 16:29:26 -0000 1.168 --- test_descr.py 9 Dec 2002 18:38:20 -0000 *************** *** 1464,1475 **** a = (1, 2, 3) d = {'abc': 123} x, a1, d1 = spam.spamlist.classmeth(*a, **d) ! veris(x, None) ! vereq((spam.spamlist,) + a, a1) vereq(d, d1) x, a1, d1 = spam.spamlist().classmeth(*a, **d) ! veris(x, None) ! vereq((spam.spamlist,) + a, a1) vereq(d, d1) def staticmethods(): --- 1464,1475 ---- a = (1, 2, 3) d = {'abc': 123} x, a1, d1 = spam.spamlist.classmeth(*a, **d) ! veris(x, spam.spamlist) ! vereq(a, a1) vereq(d, d1) x, a1, d1 = spam.spamlist().classmeth(*a, **d) ! veris(x, spam.spamlist) ! vereq(a, a1) vereq(d, d1) def staticmethods(): ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-09 13:31 Message: Logged In: YES user_id=6380 >From a brief skim of the patch, it looks like this is indeed what's needed. I guess Tim can check it in (with my helpp, I'm sitting right behind him). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-09 00:12 Message: Logged In: YES user_id=31435 Guido, does this patch match your and Fred's intent? I want to get this fixed, as it pops up a dozen times in the datetime project. Feel free to do a braindump on me tomorrow and make it my headache. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 13:51 Message: Logged In: YES user_id=11105 Ok, here's a first outline in form of a patch. Probably the same should be done for staticmethods. All the tests pass on Windows except bz2 and bsddb which I didn't build, and test_descr failes because Modules/xxsubtype.c needs to be updated. If this looks ok, I'm willing to continue - it didn't take much longer than an hour so far. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-06 12:19 Message: Logged In: YES user_id=31435 This also affects the C implementation of the datetime module. While it would be very nice to get it fixed before alpha 1, it doesn't need to be fixed before beta 1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-12-06 10:12 Message: Logged In: YES user_id=3066 I'd love to see this fixed. Priorities at work may not allow me to spend any time on this; patches would be welcome. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-06 03:19 Message: Logged In: YES user_id=11105 Will this be fixed before 2.3a? Now is the *last* chance to do this, since it changes the sematics of C code. In http://mail.python.org/pipermail/python-dev/2002- April/023574.html, Guido wrote the following: > Fred & I had a little whiteboard session. The docs indeed > disagree with the code, and we agree that the code should > be fixed. This requires some work: we'll have to introduce a > new kind of descriptor that wraps a PyMethodDef pointer > and creates a PyCFunction in response to the p_descr_get > call with the type as self. Fred will do this. Is this still the plan? Fred, are you going to implement this? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2002-11-26 05:30 Message: Logged In: YES user_id=92689 This has been open since april, and becomes immediately relevant with rhettingers dict.fromseq() classmethod addition: patch #643443. I hadn't seen this bug report before, but looking at Raymond's code I wondered why cls was passed as part of args instead of as the first arg of the C function. I ended up here... I think it's *crucial* this is fixed before the first alpha of 2.3 is released. Upping the priority by one... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 05:53 Message: Logged In: YES user_id=11105 IMO this should be fixed before 2.3 is released, so I'm raising the priority to 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470 From noreply@sourceforge.net Tue Dec 10 02:21:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 18:21:27 -0800 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: Closed >Resolution: Fixed 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-12-09 21:21 Message: Logged In: YES user_id=33168 This was fixed in Tix 1.13 ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-14 01:09 Message: Logged In: YES user_id=33229 the answer is just (untested) return list (self.tk.split(self.tk.call(self._w, 'getselection', mode ))) isn't it? I'll test it out and contribute an updated version of Tix.py - it looks like there may be some others that should be using return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-18 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 Tue Dec 10 04:16:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Dec 2002 20:16:10 -0800 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: Jeffrey Hobbs (hobbs) Date: 2002-12-09 20:16 Message: Logged In: YES user_id=72656 Interesting last couple of comments ... Anyway, I think the cause of this problem may have finally been identified by Tcl bug 651139. I have attached a patch here for it against 8.3.5. Both the 8.3.5 branch and 8.4.1+ head have this fix. Amazingly it didn't effect Tcl, but could likely have caught Tkinter (only on Windows with non- threaded builds). Oh look, not allowed to attach a patch, so I'll attach it to Tcl bug 651139. ---------------------------------------------------------------------- Comment By: christian soldan (elacademico) Date: 2002-11-30 18:07 Message: Logged In: YES user_id=659858 how do i hack my fuckers friends ---------------------------------------------------------------------- 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 Dec 10 10:38:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 02:38:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-651362 ] PyRun_SimpleFile() should use const char Message-ID: Bugs item #651362, was opened at 2002-12-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651362&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Nobody/Anonymous (nobody) Summary: PyRun_SimpleFile() should use const char Initial Comment: PyRun_SimpleFile() currently expects a char* which leads to many ugly const_cast() calls if you use string types in C++. Please change to "const char*" if possible. TIA! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651362&group_id=5470 From noreply@sourceforge.net Tue Dec 10 10:39:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 02:39:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-651363 ] PyDict_GetItemString expects char* Message-ID: Bugs item #651363, was opened at 2002-12-10 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651363&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Nobody/Anonymous (nobody) Summary: PyDict_GetItemString expects char* Initial Comment: PyDict_GetItemString currently expects a char* which leads to many ugly const_cast() calls if you use string types in C++ and try to embed Python. Please change to "const char*" if possible. TIA! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651363&group_id=5470 From noreply@sourceforge.net Tue Dec 10 18:55:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 10:55:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-651572 ] tools/i18n should be in the distribution Message-ID: Bugs item #651572, was opened at 2002-12-10 18:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651572&group_id=5470 Category: Demos and Tools Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: tools/i18n should be in the distribution Initial Comment: the directory tools/i18n should be in the distribution of python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651572&group_id=5470 From noreply@sourceforge.net Tue Dec 10 19:11:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 11:11:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-651362 ] PyRun_SimpleFile() should use const char Message-ID: Bugs item #651362, was opened at 2002-12-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651362&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) >Assigned to: Martin v. Löwis (loewis) Summary: PyRun_SimpleFile() should use const char Initial Comment: PyRun_SimpleFile() currently expects a char* which leads to many ugly const_cast() calls if you use string types in C++. Please change to "const char*" if possible. TIA! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651362&group_id=5470 From noreply@sourceforge.net Tue Dec 10 19:11:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 11:11:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-651572 ] tools/i18n should be in the distribution Message-ID: Bugs item #651572, was opened at 2002-12-10 13:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651572&group_id=5470 Category: Demos and Tools Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Guettler (guettli) >Assigned to: Tim Peters (tim_one) Summary: tools/i18n should be in the distribution Initial Comment: the directory tools/i18n should be in the distribution of python. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-10 14:11 Message: Logged In: YES user_id=31435 This has been done for the 2.3 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651572&group_id=5470 From noreply@sourceforge.net Tue Dec 10 19:11:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 11:11:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-651363 ] PyDict_GetItemString expects char* Message-ID: Bugs item #651363, was opened at 2002-12-10 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651363&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) >Assigned to: Martin v. Löwis (loewis) Summary: PyDict_GetItemString expects char* Initial Comment: PyDict_GetItemString currently expects a char* which leads to many ugly const_cast() calls if you use string types in C++ and try to embed Python. Please change to "const char*" if possible. TIA! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651363&group_id=5470 From noreply@sourceforge.net Tue Dec 10 19:12:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 11:12:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-09 03:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Finn Bock (bckfnn) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 20:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Tue Dec 10 21:30:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 13:30:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-09 03:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Nobody/Anonymous (nobody) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 20:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Tue Dec 10 23:10:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 15:10:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: Bugs item #651701, was opened at 2002-12-10 17:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Fein (pafein) Assigned to: Nobody/Anonymous (nobody) Summary: Bozo getstate w/ slots overrides base Initial Comment: The bozo __getstate__ set automatically on classes defining __slots__ overrides any __getstate__ defined in a base class. This makes writing a mixin to implement this method impossible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 From noreply@sourceforge.net Wed Dec 11 06:56:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Dec 2002 22:56:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 20:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-11 17:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 20:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply@sourceforge.net Wed Dec 11 09:01:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 01:01:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 22:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 09:01 Message: Logged In: YES user_id=33229 What's wrong with simply wrapping what Tk does with an image_create method that returns a string and an image_delete method that accepts a string? It's consistent with Tk usage. You can document the proper usage of image_delete and leave the Image class for backwards compatability. Something like: def image_create(self, imgtype, cnf={}, master=None, **kw): if not master: master = Tkinter._default_root if not master: raise RuntimeError, 'Too early to create image' if kw and cnf: cnf = _cnfmerge((cnf, kw)) elif kw: cnf = kw options = () for k, v in cnf.items(): if callable(v): v = self._register(v) options = options + ('-'+k, v) return master.tk.call(('image', 'create', imgtype,) + options) def image_delete(self, imgname): try: self.tk.call('image', 'delete', imgname) except TclError: # May happen if the root was destroyed pass ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 13:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 12:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 19:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 19:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 18:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 12:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 21:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 10:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 09:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 22:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 21:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 07:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 19:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 04:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Wed Dec 11 09:05:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 01:05:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 07:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 09:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 22:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 21:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 21:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 19:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 15:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 09:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Wed Dec 11 09:14:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 01:14:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 11:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 09:14 Message: Logged In: YES user_id=33229 My you're courageous - going with a version of Tcl that doesn't even pass its own tests :-) Been there, seen it, done it .... 8.1.4 will be out this week, which compiles with 8.4 but I don't expect it to "support" 8.4 for a while yet (they added more problems in 8.4.1). 8.3.5 is definitely "supported". Check back with me before 2.3 goes into beta and I'll do another minor release if necessary. Maybe Tk will test clean then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-20 01:36 Message: Logged In: YES user_id=31435 Parents shouldn't disagree in front of their children . Not all the Tcl or Tk tests (their tests, not ours) passed when I built 8.4.1, but I couldn't (and can't) make time to dig into that, and all the Python stuff I tried worked fine. So I don't fear 8.4, and am inclined to accept Martin's assurance that 8.4 is best for Python. We intend to put out the first 2.3 Python alpha by the end of the year, and my bet is it won't be a minute before that. If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final release out well before then. Yes? No? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 22:12 Message: Logged In: YES user_id=21627 I think the recommendation cannot apply to Python; I'm very much in favour of releasing Python 2.3 with Tk 8.4.x. So the question then is whether Python 2.3 should include Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can be expected. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 19:10 Message: Logged In: YES user_id=33229 Look on http://tix.sourceforge.net/download.shtml for Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite, but there are still issues with Tk 8.4 and it has not been widely tested with yet with 8.4.1, so we still recommend 8.3.5. (Tcl major releases often aren't stable until patch .3 or so.) If you have any problems let me know directly by email and I'll try and help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 16:35 Message: Logged In: YES user_id=31435 Does Tix 8.1.3 play with Tcl/Tk 8.4.1? The 2.3. Windows distro is set up to include the latter now. The win\common.mak file from Tix 8.1.3 doesn't have a section for Tcl/Tk 8.4, though. There appear to be several reasons Tix won't compile on my box anyway without fiddling the Tix makefiles (e.g., my VC doesn't live in \DevStudio), so before spending more time on that I'd like to know whether it's doomed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 14:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 07:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 03:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 01:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 13:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 12:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-25 12:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 11:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 18:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply@sourceforge.net Wed Dec 11 09:33:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 01:33:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-12-11 10:33 Message: Logged In: YES user_id=38376 "..consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life." ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:01 Message: Logged In: YES user_id=33229 What's wrong with simply wrapping what Tk does with an image_create method that returns a string and an image_delete method that accepts a string? It's consistent with Tk usage. You can document the proper usage of image_delete and leave the Image class for backwards compatability. Something like: def image_create(self, imgtype, cnf={}, master=None, **kw): if not master: master = Tkinter._default_root if not master: raise RuntimeError, 'Too early to create image' if kw and cnf: cnf = _cnfmerge((cnf, kw)) elif kw: cnf = kw options = () for k, v in cnf.items(): if callable(v): v = self._register(v) options = options + ('-'+k, v) return master.tk.call(('image', 'create', imgtype,) + options) def image_delete(self, imgname): try: self.tk.call('image', 'delete', imgname) except TclError: # May happen if the root was destroyed pass ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 14:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 13:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 20:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 20:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 19:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 22:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Wed Dec 11 10:21:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 02:21:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit Message-ID: Bugs item #453489, was opened at 2001-08-20 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using deiconify() hangs on exit Initial Comment: If you run the following script, and iconize the window before the after() timer, it'll restore and raise the window as it should, but then you can't exit. You have to kill winoldap with ctrl+alt+del and wait. I ran into this trying to write a portable jabber client using tkinter. This is with 2.1.1 on Windows 98. Does it every time. May be related to bug #216289. from Tkinter import * import sys def foo(): print 'foo' sys.stdout.flush() root.deiconify() print 'bar' sys.stdout.flush() root=Tk() Button(root, text='Quit', command=root.quit).pack() root.after(5000, foo) root.mainloop() ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:21 Message: Logged In: YES user_id=33229 When I say "PythonWin" I actually mean Pythonwin (the Win32-specific Python IDE, part of Mark Hammond's win32all). Running this under PythonWin illustrates this nicely, as you can see the exit code, and you can even load this into a file, ^R run, and then issue a root.destroy() from the shell window. I'm trying to get clear in my own mind the root cause of the more serious Win98 Tkinter hang on exit bug that can stop Windows from shutting down. In looking at the _tkinter code, I became suspicious of the current Pythonic practice of not bothering to call root.destroy ater the mainloop is exited. The hint here is in "nobody"'s followup that: Interestingly enough, if you add a print statement after the mainloop(), it gets printed, showing the event loop exits properly. The other hint comes from the Tk world where one always calls [exit] to exit, but in Python, the Tcl exit command is removed (and tkerror is made a no-op silencing all Tcl errors), so the Tcl finalization relies on the consequences of root.destroy. So I beseech you Guido to change the current Pythonic thinking to insist on always calling root.destoy in all sample programs to make sure that that gets done - after all it can't hurt right? As well one should change the documentation for .quit() from: "Quit the Tcl interpreter. All widgets will be destroyed." to "Quit the main loop. You must still destroy() the root." I find there is also confusion because people may not realize that if in Tkinter you have 2 Toplevel windows, your program *should not* die if you one of the toplevel windows, hence the importance of the change to the quit() documentation. (I'm still trying to get clear on 2 Tk() instances, each with its own interpreter...) To see and probe this kind of thing, it's very useful to have tkinspect or the equivalent, tixinspect. There may be still a Tk bug above and beyond this, and I asked Jeff Hobbs to try and make sure Tk was as clean as possible in exiting, and know they have done a lot over the last 6 months. But that's above and beyond this usage issue. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 15:00 Message: Logged In: YES user_id=6380 idiscovery, when you say "PythonWin" do you actually mean Pythonwin (a Win32-specific Python IDE, part of Mark Hammond's win32all)? Or do you simple mean "Python under Windows", as installed by the Python installer you get from python.org? This difference is significant; I would not expect Tkinter apps to work well using Pythonwin, because it has its own Win32 event loop. I don't understand why you'd need a root.destroy() after root.mainloop() exits -- when Python exits, it destroys the Tk windows anyway in my experience. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 11:06 Message: Logged In: YES user_id=33229 See my comments in bug 231207: IMHO all Tkinter programs need a root.destroy() after root.mainloop() Your test case DOES NOT die whether or not you deiconify it, if you run it under PythonWin. Your test case DOES die whether or not you deiconify it, whether or not you run it under PythonWin, if you add a root.destroy() after the root.mainloop() If you run it as a console script without the root.destroy() then Python reaches the end of the script and exits, without having shut Tk down first. PythonWin of course is not exiting at the end, and in the status line says the script returns with code 0. I think this is a usage/documentation error and is IMHO unrelated to the very real bug 216289. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 18:31 Message: Logged In: YES user_id=66570 Since I was also looking at #216289: Data using pythonw.exe (Taskinfo2000): Handles while running (before quit) 4 : Process 4 PID:FFF6F92D, C:\PYTHON20\PYTHONW.EXE C : Event 1 10 : Event 1 1C : Mutex 17 OLESCMLOCKMUTEX 20 : Event 1 24 : Event 1 -------------------------------------------------------- Handles while running Python.exe (before quit) |Handle||Type| |Refs||Name| 4 : Process 7 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 2 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 ThID:FFF79069, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 38 : Event 1 3C : Event 2 40 : Thread 1 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 44 : Event 1 48 : Event 2 4C : Thread 1 ThID:FFF53539, PID:FFF50719, C:\PYTHON20\PYTHON.EXE ---------------------------------------------------------- Handles AFTER trying to quit |Handle||Type| |Refs||Name| 4 : Process 4 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 1 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 38 : Event 1 3C : Event 1 40 : Thread 2 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE It appears that there is a thread NOT terminating. I just don't know how to go about finding it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-21 02:39 Message: Logged In: YES user_id=6380 I agree that this is likely the same as #216289. AFAIK it's a Tcl bug and we don't know what to do about it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-20 22:51 Message: Logged In: NO Interestingly enough, if you add a print statement after the mainloop(), it gets printed, showing the event loop exits properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 From noreply@sourceforge.net Wed Dec 11 11:59:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 03:59:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 23:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """\ #define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 12:59 Message: Logged In: YES user_id=21627 It's inconsistent with the rest of Tkinter. Everything in Tkinter is an object, and so are images. If you want strings, use plain _tkinter. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-11 10:33 Message: Logged In: YES user_id=38376 "..consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life." ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:01 Message: Logged In: YES user_id=33229 What's wrong with simply wrapping what Tk does with an image_create method that returns a string and an image_delete method that accepts a string? It's consistent with Tk usage. You can document the proper usage of image_delete and leave the Image class for backwards compatability. Something like: def image_create(self, imgtype, cnf={}, master=None, **kw): if not master: master = Tkinter._default_root if not master: raise RuntimeError, 'Too early to create image' if kw and cnf: cnf = _cnfmerge((cnf, kw)) elif kw: cnf = kw options = () for k, v in cnf.items(): if callable(v): v = self._register(v) options = options + ('-'+k, v) return master.tk.call(('image', 'create', imgtype,) + options) def image_delete(self, imgname): try: self.tk.call('image', 'delete', imgname) except TclError: # May happen if the root was destroyed pass ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 14:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-08 13:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 20:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-07 20:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 19:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 13:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 22:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-07 11:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 10:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-05 23:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 22:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 08:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 20:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 05:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply@sourceforge.net Wed Dec 11 12:01:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 04:01:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 08:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 13:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 23:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 22:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 22:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 20:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 16:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 10:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Wed Dec 11 12:40:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 04:40:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-08 17:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2002-12-11 03:40 Message: Logged In: YES user_id=86307 Here's a patch using the latest stringobject.c (which I downloaded from the CVS browser, so the date of the original file is wrong. The original should be rev. 2.198). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 10:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Wed Dec 11 12:54:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 04:54:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 01:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 06:54 Message: Logged In: YES user_id=2772 Here's an example of the type of error which is discarded by Tkinter._tkerror: from Tkinter import Button b = Button(command="expr 1/0") b.pack() b.mainloop() When "b" is pressed, "expr" will produce an "Error: divide by zero", and the equivalent wish app will show the bgerror dialog. But replaces the normal bgerror handler with one that discards the error, doing nothing. Of course, I've pointed out in an earlier comment how idiscovery can subclass Tk to handle this kind of error. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 06:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 03:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 16:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 15:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 15:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 13:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 09:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 03:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Wed Dec 11 13:21:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 05:21:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-651363 ] PyDict_GetItemString expects char* Message-ID: Bugs item #651363, was opened at 2002-12-10 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651363&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Martin v. Löwis (loewis) Summary: PyDict_GetItemString expects char* Initial Comment: PyDict_GetItemString currently expects a char* which leads to many ugly const_cast() calls if you use string types in C++ and try to embed Python. Please change to "const char*" if possible. TIA! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 14:21 Message: Logged In: YES user_id=21627 This is fixed in dictobject.c 2.137 dictobject.h 2.26 and recorded as a 2.2 patch candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651363&group_id=5470 From noreply@sourceforge.net Wed Dec 11 14:05:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 06:05:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-651362 ] PyRun_SimpleFile() should use const char Message-ID: Bugs item #651362, was opened at 2002-12-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651362&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Martin v. Löwis (loewis) Summary: PyRun_SimpleFile() should use const char Initial Comment: PyRun_SimpleFile() currently expects a char* which leads to many ugly const_cast() calls if you use string types in C++. Please change to "const char*" if possible. TIA! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 15:05 Message: Logged In: YES user_id=21627 This if now fixed in the CVS, with the changes compile.h 2.39 parsetok.h 2.20 pyerrors.h 2.64 pythonrun.h 2.56 symtable.h 2.11 parsetok.c 2.34 tokenizer.c 2.70 tokenizer.h 2.20 compile.c 2.266 errors.c 2.75 future.c 2.13 pythonrun.c 2.170 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651362&group_id=5470 From noreply@sourceforge.net Wed Dec 11 14:10:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 06:10:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 08:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 15:10 Message: Logged In: YES user_id=21627 Thanks for the example. Is this the case that this can only trigger by bugs in Tcl scripts which aren't produced by Tkinter? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 13:54 Message: Logged In: YES user_id=2772 Here's an example of the type of error which is discarded by Tkinter._tkerror: from Tkinter import Button b = Button(command="expr 1/0") b.pack() b.mainloop() When "b" is pressed, "expr" will produce an "Error: divide by zero", and the equivalent wish app will show the bgerror dialog. But replaces the normal bgerror handler with one that discards the error, doing nothing. Of course, I've pointed out in an earlier comment how idiscovery can subclass Tk to handle this kind of error. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 13:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 23:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 22:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 22:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 20:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 16:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 10:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Wed Dec 11 14:53:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 06:53:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 01:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 08:53 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 08:10 Message: Logged In: YES user_id=21627 Thanks for the example. Is this the case that this can only trigger by bugs in Tcl scripts which aren't produced by Tkinter? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 06:54 Message: Logged In: YES user_id=2772 Here's an example of the type of error which is discarded by Tkinter._tkerror: from Tkinter import Button b = Button(command="expr 1/0") b.pack() b.mainloop() When "b" is pressed, "expr" will produce an "Error: divide by zero", and the equivalent wish app will show the bgerror dialog. But replaces the normal bgerror handler with one that discards the error, doing nothing. Of course, I've pointed out in an earlier comment how idiscovery can subclass Tk to handle this kind of error. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 06:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 03:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 16:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 15:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 15:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 13:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 09:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 03:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Wed Dec 11 14:55:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 06:55:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 01:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 08:55 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is b = Button(); b.configure(command=lambda: b.tk.call("expr", "1/0")) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 08:53 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 08:10 Message: Logged In: YES user_id=21627 Thanks for the example. Is this the case that this can only trigger by bugs in Tcl scripts which aren't produced by Tkinter? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 06:54 Message: Logged In: YES user_id=2772 Here's an example of the type of error which is discarded by Tkinter._tkerror: from Tkinter import Button b = Button(command="expr 1/0") b.pack() b.mainloop() When "b" is pressed, "expr" will produce an "Error: divide by zero", and the equivalent wish app will show the bgerror dialog. But replaces the normal bgerror handler with one that discards the error, doing nothing. Of course, I've pointed out in an earlier comment how idiscovery can subclass Tk to handle this kind of error. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 06:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 03:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 16:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 15:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 15:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 13:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 09:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 03:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Wed Dec 11 16:07:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 08:07:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-652104 ] int(u"\u1234") raises UnicodeEncodeError Message-ID: Bugs item #652104, was opened at 2002-12-11 11:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: int(u"\u1234") raises UnicodeEncodeError Initial Comment: In python 2.2, int of a unicode string containing non-digit characters raises ValueError, like all other attempts to convert an invalid string or unicode to int. But in Python 2.3, it appears that int() of a unicode string si implemented differently and now can raise UnicodeEncodeError: >>> int(u"\u1234") Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string >>> I think it's important that int() of a string or unicode argument only raises ValueError to indicate invalid inputs -- otherwise one ends up writing bare excepts for conversions to string (as it is too much trouble to keep track of which Python versions can raise which exceptions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 From noreply@sourceforge.net Wed Dec 11 16:39:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 08:39:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-652104 ] int(u"\u1234") raises UnicodeEncodeError Message-ID: Bugs item #652104, was opened at 2002-12-11 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) >Summary: int(u"\u1234") raises UnicodeEncodeError Initial Comment: In python 2.2, int of a unicode string containing non-digit characters raises ValueError, like all other attempts to convert an invalid string or unicode to int. But in Python 2.3, it appears that int() of a unicode string si implemented differently and now can raise UnicodeEncodeError: >>> int(u"\u1234") Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string >>> I think it's important that int() of a string or unicode argument only raises ValueError to indicate invalid inputs -- otherwise one ends up writing bare excepts for conversions to string (as it is too much trouble to keep track of which Python versions can raise which exceptions). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 17:39 Message: Logged In: YES user_id=21627 I don't see the problem: >>> try: ... int(u"\u1234") ... except ValueError: ... print "caught" ... caught >>> issubclass(UnicodeEncodeError,ValueError) True ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 From noreply@sourceforge.net Wed Dec 11 16:45:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 08:45:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-652104 ] int(u"\u1234") raises UnicodeEncodeError Message-ID: Bugs item #652104, was opened at 2002-12-11 11:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) >Summary: int(u"\u1234") raises UnicodeEncodeError Initial Comment: In python 2.2, int of a unicode string containing non-digit characters raises ValueError, like all other attempts to convert an invalid string or unicode to int. But in Python 2.3, it appears that int() of a unicode string si implemented differently and now can raise UnicodeEncodeError: >>> int(u"\u1234") Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string >>> I think it's important that int() of a string or unicode argument only raises ValueError to indicate invalid inputs -- otherwise one ends up writing bare excepts for conversions to string (as it is too much trouble to keep track of which Python versions can raise which exceptions). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-11 11:45 Message: Logged In: YES user_id=6380 Ah, thanks. Sorry. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 11:39 Message: Logged In: YES user_id=21627 I don't see the problem: >>> try: ... int(u"\u1234") ... except ValueError: ... print "caught" ... caught >>> issubclass(UnicodeEncodeError,ValueError) True ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 From noreply@sourceforge.net Wed Dec 11 16:54:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 08:54:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-08 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Raymond Hettinger (rhettinger) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-11 11:54 Message: Logged In: YES user_id=80475 The patch looks good. Please add a couple lines of unittests to string_tests.py and test_unicode.py. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=86307 Here's a patch using the latest stringobject.c (which I downloaded from the CVS browser, so the date of the original file is wrong. The original should be rev. 2.198). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 14:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Wed Dec 11 16:56:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 08:56:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-08 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Nobody/Anonymous (nobody) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-11 11:54 Message: Logged In: YES user_id=80475 The patch looks good. Please add a couple lines of unittests to string_tests.py and test_unicode.py. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-12-11 07:40 Message: Logged In: YES user_id=86307 Here's a patch using the latest stringobject.c (which I downloaded from the CVS browser, so the date of the original file is wrong. The original should be rev. 2.198). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 14:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Wed Dec 11 17:08:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 09:08:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-09 03:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Martin v. Löwis (loewis) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 18:08 Message: Logged In: YES user_id=21627 Actually, I have test cases in my sandbox - I just got sidetracked before committing it all. So, Greg, no need for further action. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-11 17:54 Message: Logged In: YES user_id=80475 The patch looks good. Please add a couple lines of unittests to string_tests.py and test_unicode.py. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-12-11 13:40 Message: Logged In: YES user_id=86307 Here's a patch using the latest stringobject.c (which I downloaded from the CVS browser, so the date of the original file is wrong. The original should be rev. 2.198). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 20:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Wed Dec 11 19:19:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Dec 2002 11:19:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit Message-ID: Bugs item #453489, was opened at 2001-08-20 16:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Using deiconify() hangs on exit Initial Comment: If you run the following script, and iconize the window before the after() timer, it'll restore and raise the window as it should, but then you can't exit. You have to kill winoldap with ctrl+alt+del and wait. I ran into this trying to write a portable jabber client using tkinter. This is with 2.1.1 on Windows 98. Does it every time. May be related to bug #216289. from Tkinter import * import sys def foo(): print 'foo' sys.stdout.flush() root.deiconify() print 'bar' sys.stdout.flush() root=Tk() Button(root, text='Quit', command=root.quit).pack() root.after(5000, foo) root.mainloop() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-11 14:19 Message: Logged In: YES user_id=6380 It is very unpythonic to require that people destroy the root explicitly before really exiting -- first of all, GC should take care of this, second of all, when you exit anyway, who cares. If you want to take this on, find someone with commit permission who cares about the issue enough to apply your patch; or request commit permission yourself. I'm too busy to care ATM. :-( ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 05:21 Message: Logged In: YES user_id=33229 When I say "PythonWin" I actually mean Pythonwin (the Win32-specific Python IDE, part of Mark Hammond's win32all). Running this under PythonWin illustrates this nicely, as you can see the exit code, and you can even load this into a file, ^R run, and then issue a root.destroy() from the shell window. I'm trying to get clear in my own mind the root cause of the more serious Win98 Tkinter hang on exit bug that can stop Windows from shutting down. In looking at the _tkinter code, I became suspicious of the current Pythonic practice of not bothering to call root.destroy ater the mainloop is exited. The hint here is in "nobody"'s followup that: Interestingly enough, if you add a print statement after the mainloop(), it gets printed, showing the event loop exits properly. The other hint comes from the Tk world where one always calls [exit] to exit, but in Python, the Tcl exit command is removed (and tkerror is made a no-op silencing all Tcl errors), so the Tcl finalization relies on the consequences of root.destroy. So I beseech you Guido to change the current Pythonic thinking to insist on always calling root.destoy in all sample programs to make sure that that gets done - after all it can't hurt right? As well one should change the documentation for .quit() from: "Quit the Tcl interpreter. All widgets will be destroyed." to "Quit the main loop. You must still destroy() the root." I find there is also confusion because people may not realize that if in Tkinter you have 2 Toplevel windows, your program *should not* die if you one of the toplevel windows, hence the importance of the change to the quit() documentation. (I'm still trying to get clear on 2 Tk() instances, each with its own interpreter...) To see and probe this kind of thing, it's very useful to have tkinspect or the equivalent, tixinspect. There may be still a Tk bug above and beyond this, and I asked Jeff Hobbs to try and make sure Tk was as clean as possible in exiting, and know they have done a lot over the last 6 months. But that's above and beyond this usage issue. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 10:00 Message: Logged In: YES user_id=6380 idiscovery, when you say "PythonWin" do you actually mean Pythonwin (a Win32-specific Python IDE, part of Mark Hammond's win32all)? Or do you simple mean "Python under Windows", as installed by the Python installer you get from python.org? This difference is significant; I would not expect Tkinter apps to work well using Pythonwin, because it has its own Win32 event loop. I don't understand why you'd need a root.destroy() after root.mainloop() exits -- when Python exits, it destroys the Tk windows anyway in my experience. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:06 Message: Logged In: YES user_id=33229 See my comments in bug 231207: IMHO all Tkinter programs need a root.destroy() after root.mainloop() Your test case DOES NOT die whether or not you deiconify it, if you run it under PythonWin. Your test case DOES die whether or not you deiconify it, whether or not you run it under PythonWin, if you add a root.destroy() after the root.mainloop() If you run it as a console script without the root.destroy() then Python reaches the end of the script and exits, without having shut Tk down first. PythonWin of course is not exiting at the end, and in the status line says the script returns with code 0. I think this is a usage/documentation error and is IMHO unrelated to the very real bug 216289. ---------------------------------------------------------------------- Comment By: Howard Lightstone (hlightstone) Date: 2001-09-05 14:31 Message: Logged In: YES user_id=66570 Since I was also looking at #216289: Data using pythonw.exe (Taskinfo2000): Handles while running (before quit) 4 : Process 4 PID:FFF6F92D, C:\PYTHON20\PYTHONW.EXE C : Event 1 10 : Event 1 1C : Mutex 17 OLESCMLOCKMUTEX 20 : Event 1 24 : Event 1 -------------------------------------------------------- Handles while running Python.exe (before quit) |Handle||Type| |Refs||Name| 4 : Process 7 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 2 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 ThID:FFF79069, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 38 : Event 1 3C : Event 2 40 : Thread 1 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE 44 : Event 1 48 : Event 2 4C : Thread 1 ThID:FFF53539, PID:FFF50719, C:\PYTHON20\PYTHON.EXE ---------------------------------------------------------- Handles AFTER trying to quit |Handle||Type| |Refs||Name| 4 : Process 4 PID:FFF50719, C:\PYTHON20\PYTHON.EXE 8 : Console 3 C : Screen Buff 3 10 : Screen Buff 3 18 : Event 1 1C : Event 1 20 : Event 1 24 : Event 1 28 : Mutex 19 OLESCMLOCKMUTEX 2C : Event 1 30 : Event 1 34 : Thread 1 38 : Event 1 3C : Event 1 40 : Thread 2 ThID:FFF52B8D, PID:FFF50719, C:\PYTHON20\PYTHON.EXE It appears that there is a thread NOT terminating. I just don't know how to go about finding it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-20 22:39 Message: Logged In: YES user_id=6380 I agree that this is likely the same as #216289. AFAIK it's a Tcl bug and we don't know what to do about it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-20 18:51 Message: Logged In: NO Interestingly enough, if you add a print statement after the mainloop(), it gets printed, showing the event loop exits properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470 From noreply@sourceforge.net Thu Dec 12 10:38:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 02:38:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-652590 ] dynload_next needs better errors Message-ID: Bugs item #652590, was opened at 2002-12-12 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652590&group_id=5470 Category: Macintosh Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: dynload_next needs better errors Initial Comment: Dynload_next needs to give better error messages. The code in rev. 2.11 should give an idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652590&group_id=5470 From noreply@sourceforge.net Thu Dec 12 10:40:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 02:40:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-652591 ] IDE: browsing a bool crashes Message-ID: Bugs item #652591, was opened at 2002-12-12 11:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652591&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: browsing a bool crashes Initial Comment: Double-clicking a boolean in the IDE browser window causes a crash. This doesn't happen for ints and other simple variables, so I assume this simply needs one extra choice in an "if" somewhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652591&group_id=5470 From noreply@sourceforge.net Thu Dec 12 16:18:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 08:18:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-652749 ] extra __builtin__ stuff not documented Message-ID: Bugs item #652749, was opened at 2002-12-12 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652749&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: extra __builtin__ stuff not documented Initial Comment: The names that site.py adds to __builtin__ are not document. E.g. exit, quit, help, copyright, license, credits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652749&group_id=5470 From noreply@sourceforge.net Thu Dec 12 17:35:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 09:35:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-652104 ] int(u"\u1234") raises UnicodeEncodeError Message-ID: Bugs item #652104, was opened at 2002-12-11 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 Category: Unicode Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) >Summary: int(u"\u1234") raises UnicodeEncodeError Initial Comment: In python 2.2, int of a unicode string containing non-digit characters raises ValueError, like all other attempts to convert an invalid string or unicode to int. But in Python 2.3, it appears that int() of a unicode string si implemented differently and now can raise UnicodeEncodeError: >>> int(u"\u1234") Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string >>> I think it's important that int() of a string or unicode argument only raises ValueError to indicate invalid inputs -- otherwise one ends up writing bare excepts for conversions to string (as it is too much trouble to keep track of which Python versions can raise which exceptions). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-12-12 18:35 Message: Logged In: YES user_id=89016 PyUnicode_EncodeDecimal() is responsible for this change. This function was changed due to the PEP 293 implementation. In Python 2.2 it raised a ValueError, which IMHO is a bug, because as an encoding function that encodes unicode to str, it should raise a UnicodeError in case of an unencodable character. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-11 17:45 Message: Logged In: YES user_id=6380 Ah, thanks. Sorry. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 17:39 Message: Logged In: YES user_id=21627 I don't see the problem: >>> try: ... int(u"\u1234") ... except ValueError: ... print "caught" ... caught >>> issubclass(UnicodeEncodeError,ValueError) True ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652104&group_id=5470 From noreply@sourceforge.net Thu Dec 12 17:46:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 09:46:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-640236 ] zlib.decompressobj under-described. Message-ID: Bugs item #640236, was opened at 2002-11-18 18:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640236&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: zlib.decompressobj under-described. Initial Comment: While trying to implement some decompression code, (from reading the docs), I believed this was appropriate code: dco = zlib.decompressionobj() for bytes in compressed_data: s = dco.decompress(bytes, limit) while s: handle_some_data(s) s = dco.decompress('', limit) After eventually chasing back through the test_zlib.py code, I now believe the proper analog of this code should be: dco = zlib.decompressionobj() for bytes in compressed_data: s = dco.decompress(bytes, limit) while s: handle_some_data(s) s = dco.decompress( dco.unconsumed_tail, limit) The meaning of both unconsumed_tail and unused_data need a it of explanation in the docs. ---------------------------------------------------------------------- >Comment By: Scott David Daniels (scott_daniels) Date: 2002-12-12 17:46 Message: Logged In: YES user_id=493818 Here is some alternative text, with a bit more explanation. \begin{memberdesc}{unused_data} A string which contains any bytes past the end of the compressed data. That is, this remains \code{""} until the last byte that contains compression data is available. If the whole string turned out to contain compressed data, this is \code{""}, the empty string. The only way to determine where a string of compressed data ends is by actually decompressing it. This means that when compressed data is contained part of a larger file, you can only find the end of it by reading data and feeding it followed by some non-empty string into a decompression object's \method{decompress} method until the \member{unused_data} attribute is no longer the empty string. \end{memberdesc} \begin{memberdesc}{unconsumed_tail} A string that contains any data that was not consumed by the last \method{decompress} call because it exceeded the limit for the uncompressed data buffer. This data has not yet been seen by the zlib machinery, so you must feed it (possibly with further data concatenated to it) back to a subsequent \method{decompress} method call in order to get correct output. \end{memberdesc} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640236&group_id=5470 From noreply@sourceforge.net Thu Dec 12 18:32:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 10:32:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-640230 ] Discovered typo in zlib test. Message-ID: Bugs item #640230, was opened at 2002-11-18 18:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640230&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: Discovered typo in zlib test. Initial Comment: In test_zlib.py (while chasing what appears to be a documentation problem), I found a flaw in the code that tests max_length limitted output from a decompression object test. Starting at line 100, the existing code is: ... bufs.append(deco.flush()) decomp2 = ''.join(buf) if decomp2 != buf: print "max_length decompressobj failed" else: print "max_length decompressobj succeeded" ... This test will always succeed (''.join(str) == str). What seems obviously meant is: ... bufs.append(deco.flush()) decomp2 = ''.join(bufs) if decomp2 != buf: print "max_length decompressobj failed" else: print "max_length decompressobj succeeded" ... ---------------------------------------------------------------------- >Comment By: Scott David Daniels (scott_daniels) Date: 2002-12-12 18:32 Message: Logged In: YES user_id=493818 The following replacement for PyZlib_unflush addresses some of the problem, but leaves unaddressed the issues of what unused_data and unconsumed_tail should be at the end of the routine. static PyObject * PyZlib_unflush(compobject *self, PyObject *args) { int err, length = DEFAULTALLOC; PyObject * retval = NULL; unsigned long start_total_out; if (!PyArg_ParseTuple(args, "|i:flush", &length)) return NULL; if (!(retval = PyString_FromStringAndSize(NULL, length))) return NULL; ENTER_ZLIB start_total_out = self->zst.total_out; self->zst.avail_out = length; self->zst.next_out = (Byte *)PyString_AS_STRING(retval); Py_BEGIN_ALLOW_THREADS err = inflate(&(self->zst), Z_FINISH); Py_END_ALLOW_THREADS /* while Z_OK and the output buffer is full, there might be more output, so extend the output buffer and try again */ while ((err == Z_OK || err == Z_BUF_ERROR) && self->zst.avail_out == 0) { if (_PyString_Resize(&retval, length << 1) < 0) goto error; self->zst.next_out = (Byte *)PyString_AS_STRING(retval) + length; self->zst.avail_out = length; length = length << 1; Py_BEGIN_ALLOW_THREADS err = inflate(&(self->zst), Z_FINISH); Py_END_ALLOW_THREADS } /* Maybe _always_ call inflateEnd if clearing is_initialized */ if (err == Z_STREAM_END) { err = inflateEnd(&(self->zst)); if (err != Z_OK) { zlib_error(self->zst, err, "from inflateEnd()"); Py_DECREF(retval); retval = NULL; goto error; } } self->is_initialised = 0; _PyString_Resize(&retval, self->zst.total_out - start_total_out); /* ??? Here fix unused_data and unconsumed_tail */ error: LEAVE_ZLIB return retval; } ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-19 22:08 Message: Logged In: YES user_id=31435 I'd say it's a bug in flush(), or in the docs, then. They say "all pending input is processed, and a string containing the remaining uncompressed output is returned", and that's not happening here. That's pretty clearly what the author of this test *expected* to happen, too (the original bug you discovered looked much more like a typo than a failure to understand the module interface). ---------------------------------------------------------------------- Comment By: Scott David Daniels (scott_daniels) Date: 2002-11-19 21:40 Message: Logged In: YES user_id=493818 OK, The reason the code fails after the fix is as follows: deco.flush() does not return any output. The loop control says, "while we have more unexamined source." However, the decompressor can consume all of the input before it has provided all of its output. So, there are two possible fixes: 1) Minimal change: Change the loop control to say, in effect, "While we have more input or are producing output.": Around line 92: Change: bufs = [] while cb: max_length = 1 + len(cb)/10 To: bufs = [] while cb or chunk: max_length = 1 + len(cb)/10 2) More reasonable(?) change: After the insertion loop, (just before the flush) extract all remaining output: Around line 99: cb = deco.unconsumed_tail bufs.append(deco.flush()) decomp2 = ''.join(bufs) Becomes: cb = deco.unconsumed_tail while bufs[-1]: bufs.append(deco.decompress('', max_length)) bufs.append(deco.flush()) decomp2 = ''.join(bufs) --- Note, in any case, the bufs.append(deco.flush()) originally on line 100 _always_ appends a zero-length string. I would suggest changing it to simply: deco.flush() ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-19 09:50 Message: Logged In: YES user_id=6656 Assuming Tim meant what he said, not what he did: raising priority. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 20:56 Message: Logged In: YES user_id=31435 Good eye! Unfortunately, when I repair that, the test fails here -- decomp2 is a proper prefix of buf then. It's "too short". Raised priority but left unassigned (someone who understands zlib better will have to jump in). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=640230&group_id=5470 From noreply@sourceforge.net Thu Dec 12 18:54:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 10:54:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: Bugs item #651701, was opened at 2002-12-10 17:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 >Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Fein (pafein) Assigned to: Nobody/Anonymous (nobody) Summary: Bozo getstate w/ slots overrides base Initial Comment: The bozo __getstate__ set automatically on classes defining __slots__ overrides any __getstate__ defined in a base class. This makes writing a mixin to implement this method impossible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 From noreply@sourceforge.net Thu Dec 12 20:21:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 12:21:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-650653 ] str.translate does not check table len Message-ID: Bugs item #650653, was opened at 2002-12-09 03:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Martin v. Löwis (loewis) Summary: str.translate does not check table len Initial Comment: If you call str.translate without supplying the optional deletechars parameter, translate does not check to see if the table parameter has length 256. For example: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = 'hello' >>> s.translate('') '\x00\x00\x00\x00\x00' >>> s.translate('', '5') Traceback (most recent call last): File "", line 1, in ? ValueError: translation table must be 256 characters long >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-12 21:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as string_tests.py 1.26 stringobject.c 2.199 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 18:08 Message: Logged In: YES user_id=21627 Actually, I have test cases in my sandbox - I just got sidetracked before committing it all. So, Greg, no need for further action. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-11 17:54 Message: Logged In: YES user_id=80475 The patch looks good. Please add a couple lines of unittests to string_tests.py and test_unicode.py. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-12-11 13:40 Message: Logged In: YES user_id=86307 Here's a patch using the latest stringobject.c (which I downloaded from the CVS browser, so the date of the original file is wrong. The original should be rev. 2.198). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-10 20:12 Message: Logged In: YES user_id=21627 Would you like to develop a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650653&group_id=5470 From noreply@sourceforge.net Thu Dec 12 20:36:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Dec 2002 12:36:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-652888 ] bad documentation for the "type" builtin Message-ID: Bugs item #652888, was opened at 2002-12-12 15:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652888&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) Summary: bad documentation for the "type" builtin Initial Comment: After a discussion on comp.lang.python http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=7h38yyvgto8.fsf%40pc150.maths.bris.ac.uk&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.python%26start%3D0 I was suggested to submit a bug report about the documentation of the built-in "type". The official 2.2.2 documentation says: type(object) Return the type of an object. The return value is a type object. The standard module types defines names for all built-in types. For instance: >>> import types >>> if type(x) == types.StringType: print "It's a string" This is misleading since the module types does not contains all possible types, for instance does not contain StaticMethodType (which I was looking for). Moreover, people pointed out much better idioms, like >>> if type(x) is str: print "It's a string" or even (without using type) >>> if isinstance(x, str): print "It's not a moose!" Moreover, I would be happy to see in the documentation of the types module a sentence about the alternative ways of retrieving the type of an object. -- Michele Simionato - Dept. of Physics and Astronomy 210 Allen Hall Pittsburgh PA 15260 U.S.A. Phone: 001-412-624-9041 Fax: 001-412-624-9163 Home-page: http://www.phyast.pitt.edu/~micheles/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652888&group_id=5470 From noreply@sourceforge.net Fri Dec 13 10:59:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Dec 2002 02:59:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-652591 ] IDE: browsing a bool crashes Message-ID: Bugs item #652591, was opened at 2002-12-12 11:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652591&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: browsing a bool crashes Initial Comment: Double-clicking a boolean in the IDE browser window causes a crash. This doesn't happen for ints and other simple variables, so I assume this simply needs one extra choice in an "if" somewhere. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2002-12-13 11:59 Message: Logged In: YES user_id=92689 Fixed. Thanks for finding this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652591&group_id=5470 From noreply@sourceforge.net Fri Dec 13 14:40:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Dec 2002 06:40:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-13 14:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 11:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 13:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 11:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 11:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 10:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 23:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 18:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 17:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 16:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 15:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 13:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 13:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 11:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Fri Dec 13 15:09:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Dec 2002 07:09:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 11:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 16:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 15:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 12:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 14:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 13:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 12:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 12:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 11:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-16 00:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 19:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 18:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 17:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 16:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 14:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 14:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 12:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Fri Dec 13 15:27:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Dec 2002 07:27:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-653301 ] py_compile does not return error code Message-ID: Bugs item #653301, was opened at 2002-12-13 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mark Ferris (mferris1) Assigned to: Nobody/Anonymous (nobody) Summary: py_compile does not return error code Initial Comment: Since py_compile.compile() does not return an error code, the compile_all module does not return an error code and my ant build process continues merrily along even though it should failOnError. This appears to be related to an incomplete fix for bug 412436. The download attached to that defect included changes to py_compile.py and compileall.py. It looks like the py_compile.py changes were not implemented. A simple fix that has been working for me is to change the py_compile.py file as follows. This diff was done against version 1.18 of py_compile.py: 69c69 < return 0 --- > return 83d82 < return 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 From noreply@sourceforge.net Sat Dec 14 01:02:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Dec 2002 17:02:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-653542 ] PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Message-ID: Bugs item #653542, was opened at 2002-12-13 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Initial Comment: These two functions have mutually-recursive definitions in the docs (which is to say, none). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 From noreply@sourceforge.net Sat Dec 14 14:15:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Dec 2002 06:15:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-653542 ] PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Message-ID: Bugs item #653542, was opened at 2002-12-14 02:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Initial Comment: These two functions have mutually-recursive definitions in the docs (which is to say, none). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-14 15:15 Message: Logged In: YES user_id=21627 Would you like to provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 From noreply@sourceforge.net Sat Dec 14 14:37:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Dec 2002 06:37:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-653542 ] PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Message-ID: Bugs item #653542, was opened at 2002-12-13 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Initial Comment: These two functions have mutually-recursive definitions in the docs (which is to say, none). ---------------------------------------------------------------------- >Comment By: David Abrahams (david_abrahams) Date: 2002-12-14 09:37 Message: Logged In: YES user_id=52572 Thanks for asking but the problem is that I don't know what they do! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-14 09:15 Message: Logged In: YES user_id=21627 Would you like to provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 From noreply@sourceforge.net Sat Dec 14 16:15:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Dec 2002 08:15:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-653542 ] PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Message-ID: Bugs item #653542, was opened at 2002-12-14 02:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsVoidPtr()/PyLong_FromVoidPtr() Initial Comment: These two functions have mutually-recursive definitions in the docs (which is to say, none). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-14 17:15 Message: Logged In: YES user_id=21627 Something very simple: PyObject * PyLong_FromVoidPtr(void *p) { #if SIZEOF_VOID_P <= SIZEOF_LONG return PyInt_FromLong((long)p); #else #ifndef HAVE_LONG_LONG # error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long" #endif #if SIZEOF_LONG_LONG < SIZEOF_VOID_P # error "PyLong_FromVoidPtr: sizeof(LONG_LONG) < sizeof (void*)" #endif /* optimize null pointers */ if (p == NULL) return PyInt_FromLong(0); return PyLong_FromLongLong((LONG_LONG)p); #endif /* SIZEOF_VOID_P <= SIZEOF_LONG */ } ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2002-12-14 15:37 Message: Logged In: YES user_id=52572 Thanks for asking but the problem is that I don't know what they do! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-14 15:15 Message: Logged In: YES user_id=21627 Would you like to provide a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653542&group_id=5470 From noreply@sourceforge.net Sat Dec 14 22:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Dec 2002 14:24:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-653871 ] Investigate weak linking Message-ID: Bugs item #653871, was opened at 2002-12-14 23:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653871&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 2 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Investigate weak linking Initial Comment: We should investigate weak linking (Apple technote 2064) as a way to make a binary Python distribution compatible with older MacOSX releases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653871&group_id=5470 From noreply@sourceforge.net Sun Dec 15 01:39:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Dec 2002 17:39:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 10:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:39 Message: Logged In: YES user_id=33168 Leslie, do you have this problem with 2.2.2? If so, can you try idlefork? See http://sf.net/projects/idlefork ---------------------------------------------------------------------- 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 Sun Dec 15 01:49:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Dec 2002 17:49:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-594998 ] test_nis test fails on TRU64 5.1 Message-ID: Bugs item #594998, was opened at 2002-08-14 06:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Finnerty (finnertyp) Assigned to: Nobody/Anonymous (nobody) Summary: test_nis test fails on TRU64 5.1 Initial Comment: Platform: TRU64 v5.1a Ran configure with --with-dec-threads options. Also used --without-gcc although this has no impact on test failure. The ouput from ./python ./Lib/test/test_nis.py is large so I've included it in an attached file rather than pasted here. The machine that Python is being built on is a NIS server as well as client. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:49 Message: Logged In: YES user_id=33168 I fixed a similar problem on Nov 4. Can you test the latest CVS versions from the head or for 2.2.2+? ---------------------------------------------------------------------- Comment By: Patrick Finnerty (finnertyp) Date: 2002-08-15 09:06 Message: Logged In: YES user_id=594846 On TRU64 this is doucmented as foreach(instatus, inkey, inkeylen, inval, invallen, indata); int instatus; char *inkey; int inkeylen; char *inval; int invallen; char *indata; ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-15 07:05 Message: Logged In: YES user_id=21627 This sounds like some serious memory corruption is going on. Unfortunately, I can't spot a problem, so somebody with access to such a system would need to debug it. My first guess is that the type of the callback function is incorrect. Can you please find out what signatures are involved in yp_all(3)? On Solaris, the callback signature is not declared in a header, but only documented in yp_clnt(3NSL), as foreach(int instatus, char *inkey, int inkeylen, char *inval, int invallen, char *indata); ---------------------------------------------------------------------- Comment By: Patrick Finnerty (finnertyp) Date: 2002-08-15 06:02 Message: Logged In: YES user_id=594846 Uploading the output file from ./python ./Lib/test/test_nis.py. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-15 05:01 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594998&group_id=5470 From noreply@sourceforge.net Sun Dec 15 09:28:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Dec 2002 01:28:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 07:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- >Comment By: Internet Discovery (idiscovery) Date: 2002-12-15 09:28 Message: Logged In: YES user_id=33229 It's a basic computer engineering principle not to ignore errors silently, and no one has given any reason, good or otherwise, as to why this code should be in there. To not believe this problem could ever happen is to assume that there are never side effects in Tcl from Tkinter. For an example of where a bug has been obscured by this, comment out the line self.tk.createcommand('tkerror', _tkerror) in Tkinter.py and run Demo/tix/tixwidgets.py Click on the ComboBox in the ExFileSelectBox demo. The popdown scrolled list widget is being created, then destroyed. Martin I don't know how you could still assume that Tkinter does *not*, actually, drop any errors when you checked in the description of the bug over a year ago: Demo/tix/tixwidgets/BUGS.txt $Id: BUGS.txt,v 1.1 2001/03/21 07:42:07 loewis Exp $ ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 14:55 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is b = Button(); b.configure(command=lambda: b.tk.call("expr", "1/0")) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 14:53 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 14:10 Message: Logged In: YES user_id=21627 Thanks for the example. Is this the case that this can only trigger by bugs in Tcl scripts which aren't produced by Tkinter? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 12:54 Message: Logged In: YES user_id=2772 Here's an example of the type of error which is discarded by Tkinter._tkerror: from Tkinter import Button b = Button(command="expr 1/0") b.pack() b.mainloop() When "b" is pressed, "expr" will produce an "Error: divide by zero", and the equivalent wish app will show the bgerror dialog. But replaces the normal bgerror handler with one that discards the error, doing nothing. Of course, I've pointed out in an earlier comment how idiscovery can subclass Tk to handle this kind of error. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 12:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 09:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 22:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 21:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 21:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 19:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 15:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 09:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Sun Dec 15 10:28:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Dec 2002 02:28:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-639266 ] Tkinter sliently discards all Tcl errors Message-ID: Bugs item #639266, was opened at 2002-11-16 08:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Internet Discovery (idiscovery) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter sliently discards all Tcl errors Initial Comment: Tkinter silently discards all Tcl errors. Athough this may make Tkinter programs appear robust, it violates the fundamental principle that erros should be raised and dealt with. In Tkinter.py is the line self.tk.createcommand('tkerror', _tkerror) where _tkerror is defined as def _tkerror(err): """Internal function.""" pass This disables all uses of the tcl procedure bgerror from signalling background errors to the user, including I assume any errors generated in after_idle. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-15 11:28 Message: Logged In: YES user_id=21627 The comment in BUGS.txt is too mysterious to make any sense to me. It basically says "it appears there is some problem, let me know if you understand it". This was fine as it stands, but it didn't say "this is because there is a Tcl error that is dropped by Python", and so far, you haven't indicated that this is indeed the problem. Uncommenting the line, I get tons of "bad window path name" and "invalid command name" messages when running tixwidgets.py. This tells me that a) this might happen quite frequently in real life, and b) the user of the Python application can do nothing about it, they can't even disable the first message (it then asks whether further messages should be skipped) I don't feel privileged to approve a change here; you should bring this up on python-dev. My feeling is that the Tcl error message is too annoying to just remove the tkerror command; printing the message to stderr might be acceptable. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-15 10:28 Message: Logged In: YES user_id=33229 It's a basic computer engineering principle not to ignore errors silently, and no one has given any reason, good or otherwise, as to why this code should be in there. To not believe this problem could ever happen is to assume that there are never side effects in Tcl from Tkinter. For an example of where a bug has been obscured by this, comment out the line self.tk.createcommand('tkerror', _tkerror) in Tkinter.py and run Demo/tix/tixwidgets.py Click on the ComboBox in the ExFileSelectBox demo. The popdown scrolled list widget is being created, then destroyed. Martin I don't know how you could still assume that Tkinter does *not*, actually, drop any errors when you checked in the description of the bug over a year ago: Demo/tix/tixwidgets/BUGS.txt $Id: BUGS.txt,v 1.1 2001/03/21 07:42:07 loewis Exp $ ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 15:55 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is b = Button(); b.configure(command=lambda: b.tk.call("expr", "1/0")) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 15:53 Message: Logged In: YES user_id=2772 As far as I can tell, the only way _tkerror can discard an error is if it happens in an event-driven way (fired as a -command, from a binding, or from "after") and the code in question is pure tcl code. So, for instance, in b = Button(command = lambda: 1/0) the error is reported by Tkinter.Tk.report_callback_exception. So is ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 15:10 Message: Logged In: YES user_id=21627 Thanks for the example. Is this the case that this can only trigger by bugs in Tcl scripts which aren't produced by Tkinter? ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-12-11 13:54 Message: Logged In: YES user_id=2772 Here's an example of the type of error which is discarded by Tkinter._tkerror: from Tkinter import Button b = Button(command="expr 1/0") b.pack() b.mainloop() When "b" is pressed, "expr" will produce an "Error: divide by zero", and the equivalent wish app will show the bgerror dialog. But replaces the normal bgerror handler with one that discards the error, doing nothing. Of course, I've pointed out in an earlier comment how idiscovery can subclass Tk to handle this kind of error. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-11 13:01 Message: Logged In: YES user_id=21627 It's a basic engineering principle: Don't apply changes that you haven't fully understood. I still don't believe this problem could ever happen, and therefore, I still assume that Tkinter does *not*, actually, drop any errors, even though the code looks like it does. However, my believes should be irrelevant if you can demonstrate the problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:05 Message: Logged In: YES user_id=33229 What possible reason can you give to ever drop errors silently? One example is in the Python distribution that I asked you about over a year ago: Demo/tix/tixwidgets.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 23:56 Message: Logged In: YES user_id=21627 idiscovery, I still would like to see an example that demonstrates that problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 22:27 Message: Logged In: YES user_id=33229 That's right: Tkinter silently discards all background Tcl errors. All errors from Tcl are silenced by def _tkerror(err): pass So Tkinter users will never see any errors that come from any bugs in Tcl, Tk or its extensions, including of course errors that may only show up under Python. The proposed solution for this problem is simply to remove the createcomand / def _tkerror. I see no possible reason for it to be in there, and it violates the fundamental principle that errors should be raised and dealt with. Although Tkinter behaved that way since the beginning, the change takes backwards compatibility into account because it serves no good purpose that I know of to begin with. At worst buried bugs will become visible and can be dealt with. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 22:03 Message: Logged In: YES user_id=21627 It is not the case that Tkinter silently discards all Python errors. In fact, I believe it never discards any Python error silently. Can you provide an example that demonstrates otherwise? ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-17 20:57 Message: Logged In: YES user_id=33229 But why is Tkinter silencing all Tk (Tcl or Python) errors in the first place? I know I can subclass Tk, but _tkerror is clearly billed as an internal function, and the only purpose of it is to disable Tcl's bgerror reporting. This lets serious bugs go undetected. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-11-17 16:39 Message: Logged In: YES user_id=2772 You could create a subclass of Tk that creates a different 'tkerror' command. Anyway, CallWrapper (used when a function is passed to functions like .after_idle()) calls widget._report_exception, which calls Tk.report_callback_exception. So you can override this function too. Neither of these things require changing Tkinter.py. I don't seem to be permitted to attach a file, so I'm forced to paste the code. import Tkinter as _Tkinter class Tk(_Tkinter.Tk): def __init__(self, *args, **kw): _Tkinter.Tk.__init__(self, *args, **kw) self.tk.createcommand('tkerror', self.tkerror) def report_callback_exception(self, exc, val, tb): print "callback exception", exc def tkerror(self, *args): print "tkerror", args if __name__ == '__main__': w = Tk() w.after_idle(lambda: 1/0) _Tkinter.Button(w, command="expr 1/0").pack() w.mainloop() ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 10:33 Message: Logged In: YES user_id=21627 The qualification "silently discards all Tcl errors" is definitely incorrect: >>> Tkinter.Label(foo="bar") Traceback (most recent call last): File "", line 1, in ? Tkinter.Label(foo="bar") File "E:\Python22\lib\lib-tk\Tkinter.py", line 2261, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "E:\Python22\lib\lib-tk\Tkinter.py", line 1756, in __init__ self.tk.call( TclError: unknown option "-foo" Instead, it would be more correct to say that all background errors are discarded. Can you provide a script that demonstrates this problem? (i.e. one which behaves differently if the createcommand is removed from Tkinter.py) Can you propose a solution for this problem? Please take into account that Tkinter behaved that way since the beginning, so any change must take backwards compatibility into account. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639266&group_id=5470 From noreply@sourceforge.net Sun Dec 15 21:37:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Dec 2002 13:37:32 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-648658 ] xmlrpc can't do proxied HTTP Message-ID: Feature Requests item #648658, was opened at 2002-12-04 23:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=648658&group_id=5470 >Category: Python Library Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Bill Bumgarner (bbum) >Assigned to: Fredrik Lundh (effbot) Summary: xmlrpc can't do proxied HTTP Initial Comment: The current xmlrpclib can't communicate through a proxy server. In particular, the two Transport classes contained within xmlrpclib use httplib directly and, as such, do not support the proxy handling as offered by urllib. Or so it seems. I'm in dire need of support for proxies in xmlrpclib and will be investigating creating a custom Transport class that uses urllib as opposed to httplib to gain support for proxies. Assuming success, I'll post the new transport class here. In the interim, I figured I would log a bug in case anyone else is interested in working on the problem (or already has a solution :). b.bum bbum@mac.com ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2002-12-08 18:07 Message: Logged In: YES user_id=103811 As discussed on python-dev and with Fredrick Lundh, I created an HTTPTransport class that uses urllib2 to implement the HTTP transport. It works around a bug in urllib2 [handler ordering] and augments the request dispatch found in the Transport class. I'm using it in a production context and have tested it fairly heavily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=648658&group_id=5470 From noreply@sourceforge.net Mon Dec 16 04:59:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Dec 2002 20:59:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-654362 ] email: huge address lines blow stack Message-ID: Bugs item #654362, was opened at 2002-12-16 15:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654362&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: huge address lines blow stack Initial Comment: The following code will recurse until Python throws an exception: """ import email.Utils addrlist = ["foo@bar.com"] * 2000 email.Utils.getaddresses(addrlist) """ I found a huge address list in my spam archive, which is how I found the error. Attaching suggested patch that avoids recursion. bugfix candidate I guess? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654362&group_id=5470 From noreply@sourceforge.net Mon Dec 16 11:33:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 03:33:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make errors better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 06:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make errors better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Mon Dec 16 14:05:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 06:05:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-448679 ] Left to right Message-ID: Bugs item #448679, was opened at 2001-08-07 06:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470 Category: Documentation >Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Left to right Initial Comment: The Ref Man doesn't explicitly say anything about Python's left-to-right evaluation order. Strict left- to-right was Guido's intent, though, and it comes up a few times per year on c.l.py (indeed, I was just replying to a msg asking about it). The docs should get fleshed out. There's also a bug: >>> counter = 0 >>> def i(): ... global counter ... counter += 1 ... return counter ... >>> {i(): i()} {2: 1} >>> {i(): i(), i(): i()} {4: 3, 6: 5} >>> That is, key:value *pairs* are evaluated left to right, but within a single key:value pair, the value gets evaluated first. When I asked Guido about that some years ago, he agreed it was a bug. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-16 14:05 Message: Logged In: YES user_id=7887 Martin, I've checked with Jython and the examples are ok as well. I have applied as: Doc/ref/ref5.tex: 1.71 Python/compile.c: 2.267 Lib/compiler/pycodegen.py: 1.62 Misc/NEWS: 1.561 Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 10:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply it. It would be good to check that Jython meets all your expectations in this respect, and that it, in particular, executes all the examples in the documentation in the right order. This change should *not* be backported to 2.2 IMO. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 02:05 Message: Logged In: YES user_id=7887 Martin, could you please review the proposed solution? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-26 22:56 Message: Logged In: YES user_id=7887 I'm attaching a suggested solution for the problem, including documentation and reordering of dict evaluation. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 09:58 Message: Logged In: YES user_id=21627 With the patch attached, this behaviour is cast into stone (or, atleast into a SF tracker :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470 From noreply@sourceforge.net Mon Dec 16 18:24:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 10:24:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-521782 ] unreliable file.read() error handling Message-ID: Bugs item #521782, was opened at 2002-02-23 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: Accepted Priority: 8 Submitted By: Marius Gedminas (mgedmin) Assigned to: Gustavo Niemeyer (niemeyer) Summary: unreliable file.read() error handling Initial Comment: fread(3) manual page states fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero). Python only checks ferror status when the return value is zero (Objects/fileobject.c line 550 from Python-2.1.2 sources). I agree that it is a good idea to delay exception throwing until after the user has processed the partial chunk of data returned by fread, but there are two problems with the current implementation: loss of errno and occasional loss of data. Both problems are illustrated with this scenario taken from real life: suppose the file descriptor refers to a pipe, and we set O_NONBLOCK mode with fcntl (the application was reading from multiple pipes in a select() loop and couldn't afford to block) fread(4096) returns an incomplete block and sets errno to EAGAIN chunksize != 0 so we do not check ferror() and return successfully the next time file.read() is called we reset errno and do fread(4096) again. It returns a full block (i.e. bytesread == buffersize on line 559), so we repeat the loop and call fread(0). It returns 0, of course. Now we check ferror() and find it was set (by a previous fread(4096) called maybe a century ago). The errno information is already lost, so we throw an IOError with errno=0. And also lose that 4K chunk of valuable user data. Regarding solutions, I can see two alternatives: - call clearerr(f->f_fp) just before fread(), where Python currently sets errno = 0; This makes sure that we do not have stale ferror() flag and errno is valid, but we might not notice some errors. That doesn't matter for EAGAIN, and for errors that occur reliably if we repeat fread() on the same stream. We might still lose data if an exception is thrown on the second or later loop iteration. - always check for ferror() immediatelly after fread(). - regarding data loss, maybe it is possible to store the errno somewhere inside the file object and delay exception throwing if we have successfully read some data (i.e. bytesread > 0). The exception could be thrown on the next call to file.read() before performing anything else. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-16 18:24 Message: Logged In: YES user_id=7887 Applied as Objects/fileobject.c: 2.172 Doc/lib/libstdtypes.tex: 1.114 Misc/NEWS: 1.563 Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 13:23 Message: Logged In: YES user_id=21627 The patch looks good. Please apply it. If we can both agree that this is a bug fix (as it arranges to return data which were previously silently lost), I suggest to backport the patch also to the 2.2 tree (no further review needed). ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-12-01 01:55 Message: Logged In: YES user_id=7887 Thanks for noticing that Martin. Here is a new revision, with suggested documentation changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-28 11:00 Message: Logged In: YES user_id=21627 I'm still missing proposed documentation changes. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-27 15:58 Message: Logged In: YES user_id=7887 I'm attaching a new revised patch. I'll also increase the priority, to reflect the serious problems this bug could cause. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 16:18 Message: Logged In: YES user_id=7887 You're right about EAGAIN. The behavior I mentioned seems to be valid only for old Unixes, as presented here: http://www.gnu.org/manual/glibc/html_mono/libc.html So indeed we should check for both. OTOH, the above URL also mentions that EAGAIN can happen in blocking situations as well: "On some systems, reading a large amount of data from a character special file can also fail with EAGAIN if the kernel cannot find enough physical memory to lock down the user's pages." Also, the statement in the documentation you mention isn't true even without my patch. We currently check for "readbytes < requestedbytes" and break the loop if it happens. Indeed, that's one of the reasons that created the second problem I've mentioned. Enforcing this behavior, I could see that mentioned in the URL above: "Any condition that could result in EAGAIN can instead result in a successful read which returns fewer bytes than requested. Calling read again immediately would result in EAGAIN." Thusly, applying this patch we wouldn't be introducing a new behavior, but just enforcing a single behavior in every case. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 14:18 Message: Logged In: YES user_id=21627 Depends on what system you have. On Linux-i386, we have #define EWOULDBLOCK EAGAIN so it is necessarily the same thing. Can you report on what system EAGAIN happens even if the file descriptor is non-blocking? As for documentation changes: The documentation currently says Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes) I believe this statement is no longer true: with your changes, it will return less data even without hitting EOF. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-18 13:50 Message: Logged In: YES user_id=7887 Martin, EAGAIN is not the same as EWOULDBLOCK. While EWOULDBLOCK will only be issued in a situation where the filedescriptor is marked as non-blocking, EAGAIN can happen at any time, including when requestsize == -1 (read everything from the fd). If we're going to handle EAGAIN, we must ensure that the loop is not broken when it happens, instead of using the same solution proposed for EWOULDBLOCK. Do you think we should do that as well? You're right about EWOULDBLOCK not being available. I'll include the required #ifdef, and also the suggested comment. Could you please clarify what you mean in this sentence: "In any case, please update the documentation to describe the special cases that you add.". IMO, the proposed patch is not adding special cases. It's just fixing the algorithm to behave the same way in all situations. In that case, what doucmentation should be updated, in your opinion? Or perhaps you're talking about the proposed e.data solution, which would be used in other cases like EINTR similars? Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-14 08:29 Message: Logged In: YES user_id=21627 I think the processing of the error condition is wrong, in a number of ways: - Posix allows for both EAGAIN and EWOULDBLOCK to be signalled in this case. - Neither EAGAIN nor EWOULDBLOCK are guaranteed to exist on all systems. - Please add a comment to the break; to indicate what the purpose of this code is. Also, I think there are a number of other cases where bytesread might be non-zero, e.g. if EINTR was signalled. It's not clear what the best solution would be, I propose that the exception carries an attribute "data" to denote the short data. Of course, in the EINTR case, the original exception is lost and a KeyboardInterrupt is raised instead, so putting the data into the exception might be pointless... In any case, please update the documentation to describe the special cases that you add. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 16:43 Message: Logged In: YES user_id=7887 Martin, could you please review that? ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=7887 Great catch Marius! Thank you very much! I could identify the following problems from your report: - If (requestsize == -1) and after a few iterations, fread() signals EWOULDBLOCK with (chunksize == 0), all read data is lost because an exception is raised. - When (chunksize != 0) and EWOULDBLOCK is signaled, ferror() will be flagged. Then the next iteration will fail if: 1) read data has length 0 because EWOULDBLOCK is signaled again but errno is still set to 0 (I don't know why errno is not reset in that case); 2) read data has length 0 because a block with the exact requested size is read. The attached tests show these problems. The first problem is a little bit harder to trigger. I had to preset SMALLCHUNK to 4096 in fileobject.c, because my Linux refused to return a chunk greater than that from fread(). The second problem should be visible without further tweakings. I have also attached a solution to the problem. This solution works because: - If (chunksize == 0), (errno == EWOULDBLOCK) and (readbytes > 0), there's no point in raising an exception, as we got some data for the user, just like when (bytesread < buffersize). - When (chunksize != 0) and EWOULDBLOCK is signaled, it's not considered an error. OTOH, ferror() is still being set. clearerr() should be called in the stream before breaking the loop. - If (bytesread == buffersize) and (bytesrequest >= 0), it means that we already got all the requested data, and thus there's no point in trying to read more data from the file and forcing (chunksize == 0) without ferror() being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=521782&group_id=5470 From noreply@sourceforge.net Mon Dec 16 18:42:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 10:42:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-654766 ] asyncore.py and "handle_expt" Message-ID: Bugs item #654766, was opened at 2002-12-16 19:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&group_id=5470 Category: Python Library 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: asyncore.py and "handle_expt" Initial Comment: Python 2.2.2 here. Asyncore.py doesn't invoke "handle_expt" ever ("handle_expt" is documented in docs). Managing OOB data is imprescindible to handle "connection refused" errors in Windows, for example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654766&group_id=5470 From noreply@sourceforge.net Mon Dec 16 19:23:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 11:23:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception messages Message-ID: Bugs item #654783, was opened at 2002-12-16 11:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Nobody/Anonymous (nobody) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 From noreply@sourceforge.net Mon Dec 16 21:07:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 13:07:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-654846 ] datetime docs need review, LaTeX Message-ID: Bugs item #654846, was opened at 2002-12-16 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: datetime docs need review, LaTeX Initial Comment: The datetime sandbox contains a plain text file, docs.txt, with about 5,500 words of datetime documentation. This needs review by someone other than me, and LaTeXification too. Kill two birds with one tedious stone . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 From noreply@sourceforge.net Mon Dec 16 21:38:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 13:38:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Mon Dec 16 22:01:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 14:01:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception messages Message-ID: Bugs item #654783, was opened at 2002-12-16 19:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Nobody/Anonymous (nobody) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-12-16 22:01 Message: Logged In: YES user_id=35752 Couldn't doctest be modified so that it only compares the exception name only? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 From noreply@sourceforge.net Mon Dec 16 22:42:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 14:42:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 17:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Mon Dec 16 23:13:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 15:13:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 17:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 16:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Mon Dec 16 23:39:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 15:39:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-654783 ] doctest and exception messages Message-ID: Bugs item #654783, was opened at 2002-12-16 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Nobody/Anonymous (nobody) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-16 18:39 Message: Logged In: YES user_id=31435 It could, but it shouldn't: error msgs in docs that don't match reality are also an insult to users. doctest should grow some sort of option here, though, as its uses outgrew its original purposes. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-16 17:01 Message: Logged In: YES user_id=35752 Couldn't doctest be modified so that it only compares the exception name only? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 From noreply@sourceforge.net Tue Dec 17 00:25:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 16:25:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 17:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 16:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Tue Dec 17 00:39:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 16:39:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:39 Message: Logged In: YES user_id=179604 New vs. old-style classes is the problem. If I change Account to be a new-style class the problem goes away. Hope that helps. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 17:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 16:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Tue Dec 17 00:41:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 16:41:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-626275 ] missing DECREF's in embedding example Message-ID: Bugs item #626275, was opened at 2002-10-21 06: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: Closed Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) >Assigned to: Neal Norwitz (nnorwitz) 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... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 19:41 Message: Logged In: YES user_id=33168 Thanks! Checked in as Doc/ext/run-func.c 1.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626275&group_id=5470 From noreply@sourceforge.net Tue Dec 17 00:53:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 16:53:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-612969 ] property missing doc'd __name__ attr Message-ID: Bugs item #612969, was opened at 2002-09-22 17:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=612969&group_id=5470 >Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) >Assigned to: Neal Norwitz (nnorwitz) Summary: property missing doc'd __name__ attr Initial Comment: The whatsnew document states that descriptors have an attribute __name__: """ Attribute descriptors are objects that live inside class objects, and have a few attributes of their own: * __name__ is the attribute's name. """ http://www.python.org/doc/2.2.1/whatsnew/sect-rellinks.html#SECTION000320000000000000000 But in real-world tests with Python 2.2.1 on Win32: >>> class a( object ): ... b = property( ) ... >>> a.b.__name__ Traceback (most recent call last): File "", line 1, in ? AttributeError: 'property' object has no attribute '__name__' >>> Now, of course, the __name__ attribute wouldn't be that useful, given that the descriptor could be multiply-referenced under different names, but I'd guess either the value should be present, or it should not be in the whatsnew documentation. Would likely need to be handled via a mechanism similar to bound-and-unbound methods to make the __name__ attribute useful. Enjoy, Mike ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 19:53 Message: Logged In: YES user_id=33168 Properties are described in section 2.4. You are correct that properties do not have __name__ attributes. The section which references __name__ is 2.2. This section is describing descriptors like classmethod and static method which do have __name__. Therefore, I'm closing this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=612969&group_id=5470 From noreply@sourceforge.net Tue Dec 17 00:55:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 16:55:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-626275 ] missing DECREF's in embedding example Message-ID: Bugs item #626275, was opened at 2002-10-21 06: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: Closed >Resolution: Fixed Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Neal Norwitz (nnorwitz) 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... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 19:41 Message: Logged In: YES user_id=33168 Thanks! Checked in as Doc/ext/run-func.c 1.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626275&group_id=5470 From noreply@sourceforge.net Tue Dec 17 01:04:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 17:04:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-642742 ] property() builtin not documented Message-ID: Bugs item #642742, was opened at 2002-11-23 09:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642742&group_id=5470 Category: Documentation >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Just van Rossum (jvr) >Assigned to: Neal Norwitz (nnorwitz) Summary: property() builtin not documented Initial Comment: It seems the property() builtin isn't documented in lib/built-in-funcs.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 20:04 Message: Logged In: YES user_id=33168 Checked in as Doc/lib/libfuncs.tex 1.124 You got 4 for the price of one. All these got doc'ed: classmethod property staticmethod super. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642742&group_id=5470 From noreply@sourceforge.net Tue Dec 17 01:09:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 17:09:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-641111 ] Undocumented side effect of eval Message-ID: Bugs item #641111, was opened at 2002-11-20 03:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=641111&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Neal Norwitz (nnorwitz) Summary: Undocumented side effect of eval Initial Comment: Dictionary passed to eval as global name space is filled up with global variables: >>> m = {} >>> m == {} 1 >>> eval("1", m) 1 >>> m == {} 0 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 20:09 Message: Logged In: YES user_id=33168 Checked in with minor adjustments as Doc/lib/libfuncs.tex 1.125. I'm not sure if my slight rewording helped or hurt, hopefully someone will fix that. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-11-29 15:30 Message: Logged In: YES user_id=593130 Without (cvs,) latex, and diff, I think cut-and-paste paste is about best I can do. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-25 10:06 Message: Logged In: YES user_id=6656 Make a patch & I'll check it in... ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-11-24 17:42 Message: Logged In: YES user_id=593130 Suggestion: in Library Manual 2.1 eval() entry, after the second sentence, ending in 'local name space.', add If one give a *globals* dictionary that lacks a '__builtins__' entry, a copy from the current globals is added before *expession* is parsed. This means that *expression* normally has full access to the standard __builtins__ module, while restricted environments get propagated. This description is based on the tested behavior in 2.2.1. I don't know what, if any, is subject to change. (*Asterisks* indicate italics.) The 'surprise' of this side-effect has come up at least once on c.l.p. The issue of eval() and security is more frequent. The details are not obvious and occasionally important. I thus think it reasonable to add two short lines to document what happens. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-21 11:51 Message: Logged In: YES user_id=31435 Changed category to Doc and assigned to Fred, since there's no chance the implementation will change. I don't find the docs unclear, but this is deep stuff and it's certainly understanble that others may not. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-21 03:55 Message: Logged In: YES user_id=388573 I gues that a function don't have a side effect if the effect not documented. Why is dictionary passed as local name space not filled up with local variables? I think docs should say anything about this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-20 20:57 Message: Logged In: YES user_id=31435 Well, yes. That's what "global name space" means. Why would you assume it's limited to read-only? Where would you *expect* global bindings to be made, if not in the global namespace? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=641111&group_id=5470 From noreply@sourceforge.net Tue Dec 17 01:17:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 17:17:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 20:17 Message: Logged In: YES user_id=6380 Hm. Rather than me trying to check out the code and guessing what's what, could you perhaps construct a small self-contained example that demonstrates the problem? I'd also like to see some code that shows that the unpickled value is in fact wrong -- cPickle and pickle routinely create different pickles, but normally that's benign. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 19:39 Message: Logged In: YES user_id=179604 New vs. old-style classes is the problem. If I change Account to be a new-style class the problem goes away. Hope that helps. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 19:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 17:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Tue Dec 17 04:05:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 20:05:25 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414055 ] Date/time functions Message-ID: Feature Requests item #414055, was opened at 2001-04-05 13:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414055&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Cera (timcera) >Assigned to: Tim Peters (tim_one) Summary: Date/time functions Initial Comment: Currently: >>> import time >>> a = time.localtime(time.mktime((2002,5,1,1,0,0,0,0,-1))) >>> a (2002, 5, 1, 1, 0, 0, 2, 121, 1) And then that is it. What I would like is to have more date/time functions. For example: >>> date_add((2002, 5, 1, 1, 0, 0, 2, 121, 1),(0, 14, 0, 0, 0, 0, 0, 0, 0)) (2003,7,1,1,0,0,1,182,1) Would add 14 months to (2002, 5, 1, 1, 0, 0, 2, 121, 1), incrementing the other values as needed. If could have a date data type, could overload '+', '-', ...etc. >>> (2002, 5, 1, 1, 0, 0, 2, 121, 1)+(0, 14, 0, 0, 0, 0, 0, 0, 0) (2003,7,1,1,0,0,1,182,1) thanks ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:05 Message: Logged In: YES user_id=33168 Tim (Peters), can we close this now that you've implemented dates and times for 2.3? ---------------------------------------------------------------------- Comment By: Brian Mansell (bmansell) Date: 2001-04-10 15:31 Message: Logged In: YES user_id=93795 Tim, You may want to use the mxDateTime module to do what your requesting. For example... from mx.DateTime import * print now() + RelativeDateTime(months=+14) ... would return June, 10..etc.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414055&group_id=5470 From noreply@sourceforge.net Tue Dec 17 04:11:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 20:11:22 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414029 ] Request for time.standardtime(secs) Message-ID: Feature Requests item #414029, was opened at 2001-04-05 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Cera (timcera) >Assigned to: Tim Peters (tim_one) Summary: Request for time.standardtime(secs) Initial Comment: The time.localtime(secs) function always sets the dst flag to 1 and applies daylight savings time for that time zone. There isn't an easy way to get 'standard' time. A time.standardtime(secs) function would not apply the daylight savings time correction, set the dst flag to 0 (or -1?), but would correct for time zone difference from UTC. thanks tim cera ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:11 Message: Logged In: YES user_id=33168 Tim (Peters), here's another date/time one. This seems to already work for time.gmtime() which returns 0 for tm_isdst. Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 From noreply@sourceforge.net Tue Dec 17 04:19:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 20:19:21 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414055 ] Date/time functions Message-ID: Feature Requests item #414055, was opened at 2001-04-05 13:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414055&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Tim Peters (tim_one) Summary: Date/time functions Initial Comment: Currently: >>> import time >>> a = time.localtime(time.mktime((2002,5,1,1,0,0,0,0,-1))) >>> a (2002, 5, 1, 1, 0, 0, 2, 121, 1) And then that is it. What I would like is to have more date/time functions. For example: >>> date_add((2002, 5, 1, 1, 0, 0, 2, 121, 1),(0, 14, 0, 0, 0, 0, 0, 0, 0)) (2003,7,1,1,0,0,1,182,1) Would add 14 months to (2002, 5, 1, 1, 0, 0, 2, 121, 1), incrementing the other values as needed. If could have a date data type, could overload '+', '-', ...etc. >>> (2002, 5, 1, 1, 0, 0, 2, 121, 1)+(0, 14, 0, 0, 0, 0, 0, 0, 0) (2003,7,1,1,0,0,1,182,1) thanks ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-16 23:19 Message: Logged In: YES user_id=31435 Ya, Python 2.3 will have a huge pile of date, time, and duration classes and methods, including arithmetic. Curiously, it doesn't have a direct way to add months, but I'm closing this anyway . ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:05 Message: Logged In: YES user_id=33168 Tim (Peters), can we close this now that you've implemented dates and times for 2.3? ---------------------------------------------------------------------- Comment By: Brian Mansell (bmansell) Date: 2001-04-10 15:31 Message: Logged In: YES user_id=93795 Tim, You may want to use the mxDateTime module to do what your requesting. For example... from mx.DateTime import * print now() + RelativeDateTime(months=+14) ... would return June, 10..etc.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414055&group_id=5470 From noreply@sourceforge.net Tue Dec 17 04:26:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Dec 2002 20:26:35 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414029 ] Request for time.standardtime(secs) Message-ID: Feature Requests item #414029, was opened at 2001-04-05 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 >Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Cera (timcera) >Assigned to: Nobody/Anonymous (nobody) Summary: Request for time.standardtime(secs) Initial Comment: The time.localtime(secs) function always sets the dst flag to 1 and applies daylight savings time for that time zone. There isn't an easy way to get 'standard' time. A time.standardtime(secs) function would not apply the daylight savings time correction, set the dst flag to 0 (or -1?), but would correct for time zone difference from UTC. thanks tim cera ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-16 23:26 Message: Logged In: YES user_id=31435 Unassigned this. I don't know what Tim Cera is asking for, so I suggest we close this unless clarification is forthcoming. >>> import time >>> time.localtime(time.time()) (2002, 12, 16, 23, 21, 36, 0, 350, 0) >>> _.tm_isdst 0 >>> That is, it's not true that time.localtime() always sets tm_isdst to 1, nor is it true that it always applies a DST adjustment. Perhaps he has a platform bug, but we don't know which platform, or version of Python, he's talking about. On top of all that, I've no idea what "standard time" means in this context. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:11 Message: Logged In: YES user_id=33168 Tim (Peters), here's another date/time one. This seems to already work for time.gmtime() which returns 0 for tm_isdst. Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 From noreply@sourceforge.net Tue Dec 17 16:40:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 08:40:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-655269 ] PyKDE has moved - update URL Message-ID: Bugs item #655269, was opened at 2002-12-17 09:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655269&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph VanAndel (vanandel) Assigned to: Nobody/Anonymous (nobody) Summary: PyKDE has moved - update URL Initial Comment: http://www.python.org/doc/2.2.1/lib/other-gui-packages.html refers to PyKDE being hosted at http://www.thekompany.com/ PyKDE has moved to: http://www.riverbankcomputing.co.uk/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655269&group_id=5470 From noreply@sourceforge.net Tue Dec 17 16:46:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 08:46:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-655271 ] Slightly modify locals() doc? Message-ID: Bugs item #655271, was opened at 2002-12-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655271&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Slightly modify locals() doc? Initial Comment: Lib ref manual 2.1 builtin funcs: locals() says "Return a dictionary representing the current local symbol table" This can be (and has been, by experience users) interpreted as "return a *new* dictionary..." It would better describe current behavior if it said: "Update and return the dictionary...." This would make the following less surprising: >>> def f(): ... foo = 'bar' ... a = locals() ... a['foo'] = 'Guido' ... try: print a['a'] ... except: print "'a' is not in a" ... print a['foo'], locals()['foo'], a['foo'], a['a'] ... >>> f() 'a' is not in a Guido bar bar {'a': {...}, 'foo': 'bar'} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655271&group_id=5470 From noreply@sourceforge.net Tue Dec 17 16:48:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 08:48:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-583206 ] lib-dynload/*.so wrong permissions Message-ID: Bugs item #583206, was opened at 2002-07-18 06:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583206&group_id=5470 Category: Installation Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Oleg Broytmann (phd) >Assigned to: Michael Hudson (mwh) Summary: lib-dynload/*.so wrong permissions Initial Comment: /usr/local/lib/python2.1/lib-dynload/*.so files have wrong permissions after "make install". I m paranoid sysadmin and always use "umask 027" (rwxr-x---). When I compile python all files got corresponding permissions. After "su root" and "make install" all files are installed with correct permissions (rwxr-xr-x) except for those lib-dynload/*.so which are installed with wrong permissions (rwxr-x---). Permissions were correct for Python 1.5.2 and 2.0. Permissions are incorrect for Python 2.1 and 2.2. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-17 16:48 Message: Logged In: YES user_id=6656 fixed by patch 629278 ---------------------------------------------------------------------- Comment By: J. Lewis Muir (jlmuir) Date: 2002-10-27 01:09 Message: Logged In: YES user_id=527708 I've submitted a patch for this. It is patch #629278 "install lib-dynload .so files mode 555". ---------------------------------------------------------------------- Comment By: Marco De la Cruz (kimji) Date: 2002-09-25 16:13 Message: Logged In: YES user_id=617943 As an addendum, the permissions problems can manifest itself in non-obvious ways. It took me a while to figure out why I could only load some modules but not others. I don't think one should have to change the umask, instead "install" should be used consistently (the *.so files are just copied over). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2002-07-18 09:09 Message: Logged In: YES user_id=4799 I forgot to mention but I really always run "umask 022; make install" and thus all files/directories got correct permissions. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2002-07-18 09:09 Message: Logged In: YES user_id=4799 I forgot to mention but I really always run "umask 022; make install" and thus all files/directories got correct permissions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583206&group_id=5470 From noreply@sourceforge.net Tue Dec 17 16:51:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 08:51:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes Message-ID: Bugs item #534108, was opened at 2002-03-23 20:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470 Category: Build Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Ralph Corderoy (ralph) Assigned to: Michael Hudson (mwh) Summary: AIX 3.2.5 Has No chroot/fsync Prototypes Initial Comment: `make' fails for Python-2.2.1c1 under AIX 3.2.5 due to lack of prototypes for chroot and fsync in Modules/posixmodule.c. configure.in uses AC_CHECK_FUNCS to check these two can be linked into an executable, and configure correctly determines they can. $ egrep 'chroot|fsync' config.cache ac_cv_func_chroot=${ac_cv_func_chroot='yes'} ac_cv_func_fsync=${ac_cv_func_fsync='yes'} However, AC_CHECK_FUNCS essentially compiles and links #include "confdefs.h" #include char chroot(); int main() { chroot(); ; return 0; } which under AIX 3.2.5 works fine. But chroot isn't prototyped in *any* system include file, nor is fsync. Consequently, Modules/posixmodule.c has problems when it attempts to use both chroot and fsync as an rvalue for a pointer to a function. return posix_1str(args, "et:chroot", chroot); return posix_int(args, "i:fsync", fsync); Both lines cause `Undeclared identifier' errors. The solution is to conditionally add prototypes for these two functions. Modules/posixmodule.c has an icky set of conditional prototypes at the start but they rely heavily on __IBMC__, __sun__, etc, preprocessor symbols. These could be expanded to cover AIX 3.2.5's case but it may be better to use autoconf's AC_CHECK_DECLS macro, http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52. By manually adding two prototypes at the start of the source file I've confirmed the source file builds successfully. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-17 16:51 Message: Logged In: YES user_id=6656 I'm going to close this by mid January if there's no activity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-31 21:13 Message: Logged In: YES user_id=6656 Ralph, want do you want to do here? Can you supply a way of identifying aix 3 with the preprocessor? I'm worried that just bunging prototypes for chroot & fsync inside a "#if _AIX" might break AIX 4. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-27 12:54 Message: Logged In: YES user_id=21627 AC_CHECK_DECLS is not supported in autoconf 2.13, so it is not available for use in Python 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-25 13:41 Message: Logged In: YES user_id=6656 Hmm, AC_CHECK_DECLS might well be useful (and not just for these declarations). However, I'm not an autoconf guru, and really don't want to have to become one. Is there a way to identify AIX 3 using the preprocessor? Or does AIX 4 not have these prototypes either? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470 From noreply@sourceforge.net Tue Dec 17 18:20:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 10:20:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 12:20 Message: Logged In: YES user_id=179604 Attached is a greatly reduced example that demonstrates the problem. Let me know if you need more than this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 19:17 Message: Logged In: YES user_id=6380 Hm. Rather than me trying to check out the code and guessing what's what, could you perhaps construct a small self-contained example that demonstrates the problem? I'd also like to see some code that shows that the unpickled value is in fact wrong -- cPickle and pickle routinely create different pickles, but normally that's benign. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:39 Message: Logged In: YES user_id=179604 New vs. old-style classes is the problem. If I change Account to be a new-style class the problem goes away. Hope that helps. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 17:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 16:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Tue Dec 17 18:22:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 10:22:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 12:22 Message: Logged In: YES user_id=179604 I said the file was attached, but didn't give the file name. Look for the pickleError.py file for code that demonstrates the problem. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 12:20 Message: Logged In: YES user_id=179604 Attached is a greatly reduced example that demonstrates the problem. Let me know if you need more than this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 19:17 Message: Logged In: YES user_id=6380 Hm. Rather than me trying to check out the code and guessing what's what, could you perhaps construct a small self-contained example that demonstrates the problem? I'd also like to see some code that shows that the unpickled value is in fact wrong -- cPickle and pickle routinely create different pickles, but normally that's benign. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:39 Message: Logged In: YES user_id=179604 New vs. old-style classes is the problem. If I change Account to be a new-style class the problem goes away. Hope that helps. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 17:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 16:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Wed Dec 18 01:27:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 17:27:11 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-473584 ] Ctrl-C works always in IDLE Message-ID: Feature Requests item #473584, was opened at 2001-10-22 03:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=473584&group_id=5470 >Category: IDLE Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl-C works always in IDLE Initial Comment: It would be nice to have a background thread look for user keys, so that it is possible to edit or press ctrl-C if a program is running for a long time without output. This would omit the need to kill Python and restart if a computation hangs. Furthermore, it would allow to run a long computation and edit a file simultaneously. Ideally, every window in IDLE could get its own thread, so that it appears to be separate instances of Python. A special "control" window (looking like the Task Manager, but not as ubly) could then be used to stop processes. This could even be the debugger window, maybe... I admit I do not know the inner workings of IDLE, but I like it since the very beginning. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-17 20:27 Message: Logged In: YES user_id=33168 This is implemented in idlefork which will be merged with Python 2.3. For more information: http://mail.python.org/pipermail/idle-dev/2002-December/001417.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=473584&group_id=5470 From noreply@sourceforge.net Wed Dec 18 02:43:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 18:43:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-655269 ] PyKDE has moved - update URL Message-ID: Bugs item #655269, was opened at 2002-12-17 11:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655269&group_id=5470 Category: Documentation >Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Joseph VanAndel (vanandel) >Assigned to: Neal Norwitz (nnorwitz) Summary: PyKDE has moved - update URL Initial Comment: http://www.python.org/doc/2.2.1/lib/other-gui-packages.html refers to PyKDE being hosted at http://www.thekompany.com/ PyKDE has moved to: http://www.riverbankcomputing.co.uk/ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-17 21:43 Message: Logged In: YES user_id=33168 2.2.2 and the CVS HEAD were already been updated with the new link, so I'm closing. I suspect there may be lots of problems in the older docs (like 2.2.1, 2.2, 1.5.2, etc). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655269&group_id=5470 From noreply@sourceforge.net Tue Dec 17 21:53:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 13:53:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 22:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-17 22:53 Message: Logged In: YES user_id=21627 I have simplified the example even more, see t.py. Here is the explanation: cpickle only puts objects into the memo that have a reference count > 1 to them, otherwise, there can't be multiple references to the same object, and thus no backward references. pickle has no such mechanism, as it will always hold references to the objects in its various variables, and would never observe objects with a refcount 1. Of course, if you have multiple dump calls on the same pickler object, such objects won't be shared. This isn't normally an issue, since, in order to see the same object again, you'ld have to pickle its single container again, and the container will be in the memo. This only fails if you a) pickle the object itself (as you do), or b) insert the object into a different container after pickling it, and pickle that container. It appears that this behaviour has always been in cPickle.c. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 19:22 Message: Logged In: YES user_id=179604 I said the file was attached, but didn't give the file name. Look for the pickleError.py file for code that demonstrates the problem. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 19:20 Message: Logged In: YES user_id=179604 Attached is a greatly reduced example that demonstrates the problem. Let me know if you need more than this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-17 02:17 Message: Logged In: YES user_id=6380 Hm. Rather than me trying to check out the code and guessing what's what, could you perhaps construct a small self-contained example that demonstrates the problem? I'd also like to see some code that shows that the unpickled value is in fact wrong -- cPickle and pickle routinely create different pickles, but normally that's benign. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 01:39 Message: Logged In: YES user_id=179604 New vs. old-style classes is the problem. If I change Account to be a new-style class the problem goes away. Hope that helps. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 01:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 00:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 23:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Tue Dec 17 13:22:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 05:22:36 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414029 ] Request for time.standardtime(secs) Message-ID: Feature Requests item #414029, was opened at 2001-04-05 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 Category: Extension Modules Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Tim Cera (timcera) >Assigned to: Neal Norwitz (nnorwitz) Summary: Request for time.standardtime(secs) Initial Comment: The time.localtime(secs) function always sets the dst flag to 1 and applies daylight savings time for that time zone. There isn't an easy way to get 'standard' time. A time.standardtime(secs) function would not apply the daylight savings time correction, set the dst flag to 0 (or -1?), but would correct for time zone difference from UTC. thanks tim cera ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-17 08:22 Message: Logged In: YES user_id=33168 Tim Cera, I will close this in about a month unless you can provide clarification. I believe there may have been some issues with the DST flag in earlier versions of Python. However, these have been fixed. Also, with the new Date & Time classes Tim has added for Python 2.3, these should provide the functionality you want. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-16 23:26 Message: Logged In: YES user_id=31435 Unassigned this. I don't know what Tim Cera is asking for, so I suggest we close this unless clarification is forthcoming. >>> import time >>> time.localtime(time.time()) (2002, 12, 16, 23, 21, 36, 0, 350, 0) >>> _.tm_isdst 0 >>> That is, it's not true that time.localtime() always sets tm_isdst to 1, nor is it true that it always applies a DST adjustment. Perhaps he has a platform bug, but we don't know which platform, or version of Python, he's talking about. On top of all that, I've no idea what "standard time" means in this context. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:11 Message: Logged In: YES user_id=33168 Tim (Peters), here's another date/time one. This seems to already work for time.gmtime() which returns 0 for tm_isdst. Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 From noreply@sourceforge.net Tue Dec 17 18:45:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 10:45:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-654846 ] datetime docs need review, LaTeX Message-ID: Bugs item #654846, was opened at 2002-12-16 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: A.M. Kuchling (akuchling) Summary: datetime docs need review, LaTeX Initial Comment: The datetime sandbox contains a plain text file, docs.txt, with about 5,500 words of datetime documentation. This needs review by someone other than me, and LaTeXification too. Kill two birds with one tedious stone . ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-17 13:45 Message: Logged In: YES user_id=11375 I'm volunteering for this -- I need to write a whatsnew section on datetime anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 From noreply@sourceforge.net Tue Dec 17 16:48:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 08:48:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700 Message-ID: Bugs item #425007, was opened at 2001-05-18 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Michael Hudson (mwh) Summary: Python 2.1 installs shared libs with mode 0700 Initial Comment: I have gone back and tried Python 1.6 and 2.0. Both work fine. When I install Python 2.1, everything is broken. The problem is that when a module is a shared library (.so), python refuses to load the module. Example: import os import sys import SocketServer Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/SocketServer.py", line 126, in ? import socket File "/usr/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Now, do a "locate _socket.so" and I get: /usr/lib/python2.1/site-packages/_socket.so /usr/lib/python2.1/lib-dynload/_socket.so Clearly they are there, it's just that Python refuses to load them. I made Python 2.1 from source as fetched from the 2.1 tar ball. It makes cleanly. During the installation, I see some items that I believe to be minor that popup, but don't currectly expect that they are the problem. I have tried many times using different configure options to get this to work, deleting the previous installation each time. I've even tried installing in different locations. As is, Python 2.1 is completely broken for me. Surely I'm not the only one having this problem, especially since 1.5, 1.6, and 2.0 all work correctly. Any help would be great. BTW, doing a "print sys.path" gives me: ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/lib/python2.1/site-packages'] As you can see, lib-dynload is in the path, so I'm not really sure what's going on. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-17 16:48 Message: Logged In: YES user_id=6656 Fixed in patch 629278 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-08 14:20 Message: Logged In: YES user_id=6656 patch #629278 promises to help with this. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-21 00:47 Message: Logged In: NO Found a similar problem on Mac OS X's command line installation of Python 2.2.1. Darwin kernel 5.4 OS X 10.1.4. Apple's gcc 2.95.2. Built as regular user, umask 077. Ran make install as root, umask 022. All files in /usr/local/lib/python-2.2/lib-dynload were mode 711, which is not sufficient for python to load them. Same error as this problem "ImportError: No module named time". Error is clearer when viewed as: >>> help() help> modules time [Traceback redacted for brevity] IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.2/lib-dynload/MacOS.so' Suggest you add a comment on this to the README's Troubleshooting section. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-16 14:28 Message: Logged In: YES user_id=6656 I'll do something about this at some point. Using copy_tree to install shared libraries is gross. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-22 07:24 Message: Logged In: YES user_id=149084 INSTALLATION: Confirm. Built with umask 077, group and others have no permissions in source tree. (Note that if I su to install, the 077 follows! ok, install with umask of 022, normal for root.). Everything in installation looks ok except for lib-dynload, which has 700 permissions on files. No _socket.so in site-packages. REINSTALLATION: I suspect there is more to this than distutils...Redo the build with umask 022. Then chmod the whole previously installed tree to 700 and if you then repeat the install on top of it you find that while the .py files have been correctly copied by /usr/bin/install with 644, the .pyc and .pyo are still 700 though recompiled. This also happens in 1.5.2. The lib-dynload files are 755. This is with a umask of 022 for both the build user and root. Finally, delete a few files from lib-dynload, chmod the rest to 700, and make install again! The deleted files are restored at 755, the rest stay at 700. In general, messed up permissions are not fixed by a re-install. It would seem desirable that re-installing should result in exactly the same install tree as the initial install, including permissions, except that any non-distribution files (e.g. "site-packages") added by the user would be unaffected. If the user had modified some distribution .py files they would be reverted by the re-install, which does seem to be the case. A broken installation could be repaired by re-installing. Would that be a reasonable policy? Or is it too difficult to fix up all the permissions? A compromise might be to delete the .pyo .pyc before compiling, and explicitly chmod all the lib-dynload files during install. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-05-21 21:15 Message: Logged In: YES user_id=11375 Reclassifying as a Distutils bug. The install_lib subcommand simply copies the contents of the BUILD/ tree. It needs to pointedly ignore the umask and set the proper permissions on the installed files. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 20:32 Message: Logged In: YES user_id=6380 Assigning this to Andrew -- clearly the setup.py script (or distutils) needs to be fixed to fix this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-21 20:24 Message: Logged In: YES user_id=6380 I didn't mean to imply that you did something incorrectly. I just meant that there was some interaction between your system and Python that didn't work out the way it was supposed to be. Since Python installs correctly on most systems, I was implying that there's something unusual in your system that the Python install procedure doesn't anticipate. The mode 0700 for the shared libraries is a big hint at what was wrong (and if you had done an ls -l of the file when first reporting this we would have figured out the problem much quicker). Is perhaps the umask of the user who built (not installed) the files set to 077? In that case, the cause is that the "make install" by root doesn't change the file modes to something more reasonable (I've confirmed that this indeed happens). I'll look into whether this can be fixed. I'm changing the subject line of this bug report to reflect more accurately that the problem is with the file modes of shared libs. I still believe that the _socket.so in site-packages could not have been placed there by the normal Python install procedure. ---------------------------------------------------------------------- Comment By: Greg Copeland (oracle) Date: 2001-05-21 16:13 Message: Logged In: YES user_id=40173 The problem is that the installation is partially broken. It didn't install the shared libraries with proper permissions. When Python installed the shared libs, it installed the libs as root.root having 0700 permissions. When I tried to execute it as a normal user, obviously, it fails to load the shared lib. Python then, incorrectly reports that the shared lib can not be found. Of course, the correct solution is for Python to accurately report the problem and to have the installation always install the libraries with correct ownership and permission. I don't think I'm asking for too much here. Seems pretty reasonable to me. Anyone stating that I did not install correctly is woefully incorrect. Simply put, the installation is not 100%. As for some of the libraries existing twice. Well, simply put, the installation is not 100%. At any rate, I think it's safe to close this bug but we might want to add it to the faq-o-matic somewhere or some such thing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-05-20 18:35 Message: Logged In: YES user_id=6380 Clearly it's something you have done to yourself. :-) The question is how to find out what. Try "python -v" or even "python -vv" and see what it prints when you try to import _socket. This should give you some clues (it shows where it searches for modules during import). As kbk says, that other _socket.so is mysterious. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2001-05-20 01:16 Message: Logged In: YES user_id=149084 Well, import SocketServer works ok for me with Python built both from the 2.1 tar file and the 2.2a0 CVS tree. I'm running Linux 2.2.5 (RH 6.2) on Pentium. Did you make clean after changing the configure options? It is not normal to have _socket.so in .../site-packages; it should be only in .../lib-dynload. Default installation has only the README file in site-packages. Your sys.path looks normal, except that Python default installs at /usr/local/[bin/lib]. I tried a build targeted at /usr/[bin/lib] and it was ok. You could try make clobber, but it's almost as fast to start over. Try a vanilla installation: 1. delete your install tree @ /usr/local/lib/python2.1 (and/or /usr/lib) 2. delete your source tree from wherever you unpacked the tar file. 3. untar again, cd to source directory it created 4. without changing any files, and no configure options, run ./configure, then make, then make install If that doesn't help, what Linux are you running, on what box, and where did you get your 2.1 tar file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470 From noreply@sourceforge.net Wed Dec 18 04:18:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Dec 2002 20:18:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-654846 ] datetime docs need review, LaTeX Message-ID: Bugs item #654846, was opened at 2002-12-16 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: datetime docs need review, LaTeX Initial Comment: The datetime sandbox contains a plain text file, docs.txt, with about 5,500 words of datetime documentation. This needs review by someone other than me, and LaTeXification too. Kill two birds with one tedious stone . ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-17 23:18 Message: Logged In: YES user_id=31435 Outstanding -- thanks, Andrew! I burned too many candles at both ends while scrambling to finish the code, and I'm sure parts of the docs make no sense. Feel free to bug me in email about the incomprehensible parts. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-17 13:45 Message: Logged In: YES user_id=11375 I'm volunteering for this -- I need to write a whatsnew section on datetime anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654846&group_id=5470 From noreply@sourceforge.net Wed Dec 18 13:13:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Dec 2002 05:13:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-654866 ] pickle and cPickle not equivalent Message-ID: Bugs item #654866, was opened at 2002-12-16 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: pickle and cPickle not equivalent Initial Comment: Ignoring cosmetic differences, cPickle is not properly pickling references to items in its memo, while pickle does the right thing. Attached are two files, created by the same process, one using pickle, the other cPickle. I'll describe the important difference. First we pickle a python graph (Bank) that contains references to accounts. Then we pickle two transactions (DepositOrWithdrawal) that contain references to one of the accounts. The pickle version works fine and does a get of the account pickled with the Bank: (ccommands DepositOrWithdrawal p20 g2 Ntp21 R(dp22 g6 F1039911613.244611 sS'acnt' p23 g13 sS'amount' p24 I555 sbp25 .g0 (g20 g2 Ntp26 R(dp27 g6 F1039911618.384868 sg23 g13 sg24 I555 sbp28 . But the cPickle version does it wrong. For the first transaction it puts a new account instance with a get to the dictionary of the account in the Bank. And on pickling the second transaction it gets a reference to the account instance from the first transaction: (ccommands DepositOrWithdrawal p18 g3 NtRp19 (dp20 g7 F1039910911.252528 sS'acnt' p21 (iaccount Account p22 g13 bsS'amount' p23 I555 sb.g1 (g18 g3 NtRp24 (dp25 g7 F1039910918.068189 sg21 g22 sg23 I555 sb. Let me know if you need more details than this. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-18 08:13 Message: Logged In: YES user_id=6380 SO it's not a bug. Closed. (Thanks, Martin, for the analysis!) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-17 16:53 Message: Logged In: YES user_id=21627 I have simplified the example even more, see t.py. Here is the explanation: cpickle only puts objects into the memo that have a reference count > 1 to them, otherwise, there can't be multiple references to the same object, and thus no backward references. pickle has no such mechanism, as it will always hold references to the objects in its various variables, and would never observe objects with a refcount 1. Of course, if you have multiple dump calls on the same pickler object, such objects won't be shared. This isn't normally an issue, since, in order to see the same object again, you'ld have to pickle its single container again, and the container will be in the memo. This only fails if you a) pickle the object itself (as you do), or b) insert the object into a different container after pickling it, and pickle that container. It appears that this behaviour has always been in cPickle.c. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 13:22 Message: Logged In: YES user_id=179604 I said the file was attached, but didn't give the file name. Look for the pickleError.py file for code that demonstrates the problem. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-17 13:20 Message: Logged In: YES user_id=179604 Attached is a greatly reduced example that demonstrates the problem. Let me know if you need more than this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 20:17 Message: Logged In: YES user_id=6380 Hm. Rather than me trying to check out the code and guessing what's what, could you perhaps construct a small self-contained example that demonstrates the problem? I'd also like to see some code that shows that the unpickled value is in fact wrong -- cPickle and pickle routinely create different pickles, but normally that's benign. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 19:39 Message: Logged In: YES user_id=179604 New vs. old-style classes is the problem. If I change Account to be a new-style class the problem goes away. Hope that helps. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 19:25 Message: Logged In: YES user_id=179604 I forgot to mention that one of the classes that gets pickled is the Clock class, which is in pypersyst.clock. Clock is a new style class, as is transaction.Transaction, the base class for the transactions the appear in commands.py. Is there a possible problem with mixing old and new-style classes in the same pickle file? Then again, pickle does it fine, cPickle does not. So we're back to where we started. ---------------------------------------------------------------------- Comment By: Patrick K. O'Brien (pobrien) Date: 2002-12-16 18:13 Message: Logged In: YES user_id=179604 The classes are part of a sample app that someone else wrote. Their lack of Python experience shows a bit. The system that is doing the pickling was written by me. It is part of the PyPerSyst project: http://sourceforge.net/projects/pypersyst You can check out the files from CVS. The storage.singlefile module is where the pickling takes place. I commented out the cPickle import and used pickle instead to find the problem. The particular classes being pickled are defined in the files in the sandbox/pobrien/plyonsbank directory: bank.py is the main app and contains the Bank class, account.py contains the Account class, command.py contains a variety of transaction classes, and console.py is the interface. The pypersyst package needs to be on the Python path, but the sandbox stuff doesn't. Hope that helps. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-16 17:42 Message: Logged In: YES user_id=6380 I'd need the code for the classes before I can delve into this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654866&group_id=5470 From noreply@sourceforge.net Wed Dec 18 15:23:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Dec 2002 07:23:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-655802 ] cPickle not always same as pickle Message-ID: Bugs item #655802, was opened at 2002-12-18 09:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655802&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle not always same as pickle Initial Comment: Please see the previous bug report for background details: [ python-Bugs-654866 ] pickle and cPickle not equivalent The basic problem is that in certain rather rare (but not *that* rare either, imo) situations cPickle produces a pickle file that cannot reconstruct the same class instance identities as the pickle file produced by pickle. In addition, this appears to be true about pickling old-style class instances, but not pickling new-style class instances. So changing a class from old-style to new-style can change what gets pickled by cPickle. Here are items from the current docs that are candidates for clarification. My commentary appears within brackets: The data streams the two modules produce are guaranteed to be interchangeable. [Depends on the definition of interchangeable. I'd like to see something about reconstructability as well.] The pickle module keeps track of the objects it has already serialized, so that later references to the same object won't be serialized again. [Not true for cPickle, which apparently only keeps track if the refcount > 1. Note that this statement has never been true about instances of simple object types, like int and string.] If the same object is pickled by multiple dump() calls, the load() will all yield references to the same object. [Depends on whether you consider an object pickled as part of a container, and later pickled independently, as pickling the same object. If you expect that load() will yield references to the same object (and why wouldn't you, right? But that's why I'm disturbed by this.) then you need to be aware of the situations in which cPickle decides not to keep track.] The pickle data stream produced by pickle and cPickle are identical, so it is possible to use pickle and cPickle interchangeably with existing pickles. [This statement is part true and part false. The pickle data streams are not identical - they are often cosmetically different and occassionally substantially different. And this isn't really the reason the data streams are interchangeable. That has to do with the structure of the data stream, not the content of the data stream. We need to make it clear that the content isn't guaranteed to be identical, even though the structure of existing pickles can be read by either pickle or cPickle.] There are additional minor differences in API between cPickle and pickle, however for most applications, they are interchangable. More documentation is provided in the pickle module documentation, which includes a list of the documented differences. [Applications that care about object identity will want to be aware of the limitation of the cPickle memoization capability and how it differs from the pickle version.] Footnotes ... pickles3.13 Since the pickle data format is actually a tiny stack-oriented programming language, and some freedom is taken in the encodings of certain objects, it is possible that the two modules produce different data streams for the same input objects. However it is guaranteed that they will always be able to read each other's data streams. [Again, readability is not good enough for applications that expect object reconstuction equivalence.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655802&group_id=5470 From noreply@sourceforge.net Thu Dec 19 00:14:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Dec 2002 16:14:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-656049 ] string.trim does not have 2 arguments Message-ID: Bugs item #656049, was opened at 2002-12-18 15:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656049&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Sowka (msowka) Assigned to: Nobody/Anonymous (nobody) Summary: string.trim does not have 2 arguments Initial Comment: 2.2.2 python documentation lists string.trim having two arguements: strip(s[, chars]) Return a copy of the string with leading and trailing characters removed. If chars is omitted or None, whitespace characters are removed. If given and not None, chars must be a string; the characters in the string will be stripped from the both ends of the string this method is called on. On my RedHat 8.0 version of python (2.2.1) string.strip is only available with one argument, and I was able to confirm with others running 2.2.2 that it acutally only has 1. no 'chars' argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656049&group_id=5470 From noreply@sourceforge.net Thu Dec 19 01:17:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Dec 2002 17:17:39 -0800 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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-12-18 20:17 Message: Logged In: YES user_id=149084 On Linux, using 2.2.1, I don't see the problem. IDLE starts with '' as sys.path[0] and expands it to the absolute path of the directory in which it was started. Idlefork on Linux is the same. Python 2.2.1 (#1, Dec 14 2002, 21:10:27) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import sys >>> sys.path ['/home/kbk', '/usr/lib/python2.2/Tools/idle', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] >>> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:39 Message: Logged In: YES user_id=33168 Leslie, do you have this problem with 2.2.2? If so, can you try idlefork? See http://sf.net/projects/idlefork ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-14 08: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 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 Thu Dec 19 03:17:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Dec 2002 19:17:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-656049 ] string.trim does not have 2 arguments Message-ID: Bugs item #656049, was opened at 2002-12-18 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656049&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michael Sowka (msowka) Assigned to: Nobody/Anonymous (nobody) Summary: string.trim does not have 2 arguments Initial Comment: 2.2.2 python documentation lists string.trim having two arguements: strip(s[, chars]) Return a copy of the string with leading and trailing characters removed. If chars is omitted or None, whitespace characters are removed. If given and not None, chars must be a string; the characters in the string will be stripped from the both ends of the string this method is called on. On my RedHat 8.0 version of python (2.2.1) string.strip is only available with one argument, and I was able to confirm with others running 2.2.2 that it acutally only has 1. no 'chars' argument. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-18 22:17 Message: Logged In: YES user_id=33168 Sigh, you are correct that 2.2.1 (and 2.2) did not have two arguments. The second argument was inadvertantly added to string objects in 2.2.2, though. I believe the string module did not have the capability in 2.2.2. However, to keep the string module and string object in sync, both will have 2 arguments in 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656049&group_id=5470 From noreply@sourceforge.net Thu Dec 19 17:20:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Dec 2002 09:20:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-656392 ] binascii.a2b_base64 with non base64 data Message-ID: Bugs item #656392, was opened at 2002-12-19 18:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656392&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: binascii.a2b_base64 with non base64 data Initial Comment: python 2.2.2 or cvs, platform any binascii.a2b_base64 allocates buffer for data at startup, at end data it truncated to decoded size if it is bigger than 0, but what about invalid data where every character is non base64 - space, \r,\n ? Buffer remains allocated to bin_len but resulting data length is 0 and it isnt truncated as random data will be returned demo.py import base64 data = '\n' result = base64.decodestring(data) print map(ord,result) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656392&group_id=5470 From noreply@sourceforge.net Thu Dec 19 18:07:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Dec 2002 10:07:11 -0800 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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) Assigned to: Nobody/Anonymous (nobody) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-12-19 13:07 Message: Logged In: YES user_id=149084 In W2K I changed the Start In item in the IDLE button properties to d:\mydoc\PythonFiles, and then ran a short script saved in that directory. Note that the Start In directory becomes sys.path[1]. I'm looking at a cleaner way to do this in Idlefork, probably by adding the directory of the current file to sys.path. You could also frob IDLE's sys.path. Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import sys >>> sys.path ['D:\PROGRA~1\PYTHON\Tools\idle', 'D:\mydoc\PythonFiles', 'D:\Program Files\Python\DLLs', 'D:\Program Files\Python\lib', 'D:\Program Files\Python\lib\lib- tk', 'D:\Program Files\Python', 'D:\Program Files\Python\lib\site- packages'] >>> import foo Foo is a script which will print its current working directory D:\mydoc\PythonFiles >>> import os >>> os.listdir(".") ['foo.py', 'foo.pyc'] >>> ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-12-18 20:17 Message: Logged In: YES user_id=149084 On Linux, using 2.2.1, I don't see the problem. IDLE starts with '' as sys.path[0] and expands it to the absolute path of the directory in which it was started. Idlefork on Linux is the same. Python 2.2.1 (#1, Dec 14 2002, 21:10:27) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import sys >>> sys.path ['/home/kbk', '/usr/lib/python2.2/Tools/idle', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] >>> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:39 Message: Logged In: YES user_id=33168 Leslie, do you have this problem with 2.2.2? If so, can you try idlefork? See http://sf.net/projects/idlefork ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-14 08: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 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 Fri Dec 20 13:37:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Dec 2002 05:37:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-656817 ] Bug in week calculation of time module Message-ID: Bugs item #656817, was opened at 2002-12-20 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Christian Loth (chloth) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in week calculation of time module Initial Comment: Noticed while writing an application in connection with PostgreSQL. Because of Leapyears, the year 1998 had 53 weeks, instead of the normal 52 weeks. PostgreSQL does ist correctly: SELECT EXTRACT(WEEK FROM TIMESTAMP'1998-31-12 20:38:40'); date_part ----------- 53 (1 row) However the python equivalent fails, neither U nor W gets it right: >>> int(strftime("%U", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> int(strftime("%W", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 From noreply@sourceforge.net Fri Dec 20 17:13:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Dec 2002 09:13:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-656817 ] Bug in week calculation of time module Message-ID: Bugs item #656817, was opened at 2002-12-20 08:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Christian Loth (chloth) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in week calculation of time module Initial Comment: Noticed while writing an application in connection with PostgreSQL. Because of Leapyears, the year 1998 had 53 weeks, instead of the normal 52 weeks. PostgreSQL does ist correctly: SELECT EXTRACT(WEEK FROM TIMESTAMP'1998-31-12 20:38:40'); date_part ----------- 53 (1 row) However the python equivalent fails, neither U nor W gets it right: >>> int(strftime("%U", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> int(strftime("%W", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-20 12:13 Message: Logged In: YES user_id=31435 Have you read the docs for strftime()? strftime() is defined by the ANSI C standard, not by SQL 1998-01-01 was in "week 0" according to ANSI C, so the 53rd week of the year is week 52. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 From noreply@sourceforge.net Sat Dec 21 09:45:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 01:45:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-656817 ] Bug in week calculation of time module Message-ID: Bugs item #656817, was opened at 2002-12-20 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Christian Loth (chloth) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in week calculation of time module Initial Comment: Noticed while writing an application in connection with PostgreSQL. Because of Leapyears, the year 1998 had 53 weeks, instead of the normal 52 weeks. PostgreSQL does ist correctly: SELECT EXTRACT(WEEK FROM TIMESTAMP'1998-31-12 20:38:40'); date_part ----------- 53 (1 row) However the python equivalent fails, neither U nor W gets it right: >>> int(strftime("%U", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> int(strftime("%W", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> ---------------------------------------------------------------------- >Comment By: Christian Loth (chloth) Date: 2002-12-21 10:45 Message: Logged In: YES user_id=553797 If that is so, how do you explain the following (again PostgreSQL vs. Python comparison). SELECT EXTRACT(WEEK FROM TIMESTAMP'1999-12-31 20:38:40'); date_part ----------- 52 (1 row) >>> int(strftime("%U", strptime("1999-12-31", "%Y-%m-%d"))) 52 Does that mean, according to your explaination, that 1999 had 53 weeks? (which of course it hadn't). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-20 18:13 Message: Logged In: YES user_id=31435 Have you read the docs for strftime()? strftime() is defined by the ANSI C standard, not by SQL 1998-01-01 was in "week 0" according to ANSI C, so the 53rd week of the year is week 52. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 From noreply@sourceforge.net Sat Dec 21 16:45:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 08:45:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-656817 ] Bug in week calculation of time module Message-ID: Bugs item #656817, was opened at 2002-12-20 08:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Christian Loth (chloth) >Assigned to: Tim Peters (tim_one) Summary: Bug in week calculation of time module Initial Comment: Noticed while writing an application in connection with PostgreSQL. Because of Leapyears, the year 1998 had 53 weeks, instead of the normal 52 weeks. PostgreSQL does ist correctly: SELECT EXTRACT(WEEK FROM TIMESTAMP'1998-31-12 20:38:40'); date_part ----------- 53 (1 row) However the python equivalent fails, neither U nor W gets it right: >>> int(strftime("%U", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> int(strftime("%W", strptime("1998-12-31", "%Y-%m-%d"))) 52 >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-21 11:45 Message: Logged In: YES user_id=31435 Well, yes, 1999 spanned *parts* of 53 calendar weeks. Every year does, since 365 = 7*52 + 1 -- no year fits wholly within 52 calendar weeks. %U considers weeks to begin on Sunday. 1999-01-01 was a Friday, and it and the next day (Saturday) were in "week 0" according to %U rules. 1999-01-03 was the first Sunday, so was in "week 1" according to %U rules. 1999-01-10 was the start of "week 2", 1999-01-17 the start of "week 3", and so on. 1999-12-26 was the start of "week 52". Read the strftime docs. You don't have to get ANSI's, the strftime format codes are also documented in Python's Library Ref Man. I don't know what SQL's rules are, but they're clearly different. That's not a bug in strftime, so closing this as invalid. If what SQL returns is really the ISO 8601 week number, then the new datetime module in Python 2.3 supplies that via the date isocalendar() method. Like so: >>> from datetime import * >>> date(1999, 12, 31).isocalendar() (1999, 52, 5) >>> date(1998, 12, 31).isocalendar() (1998, 53, 4) >>> That appears to match the "week numbers" you're fixated on. ---------------------------------------------------------------------- Comment By: Christian Loth (chloth) Date: 2002-12-21 04:45 Message: Logged In: YES user_id=553797 If that is so, how do you explain the following (again PostgreSQL vs. Python comparison). SELECT EXTRACT(WEEK FROM TIMESTAMP'1999-12-31 20:38:40'); date_part ----------- 52 (1 row) >>> int(strftime("%U", strptime("1999-12-31", "%Y-%m-%d"))) 52 Does that mean, according to your explaination, that 1999 had 53 weeks? (which of course it hadn't). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-20 12:13 Message: Logged In: YES user_id=31435 Have you read the docs for strftime()? strftime() is defined by the ANSI C standard, not by SQL 1998-01-01 was in "week 0" according to ANSI C, so the 53rd week of the year is week 52. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=656817&group_id=5470 From noreply@sourceforge.net Sat Dec 21 18:29:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 10:29:35 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414029 ] Request for time.standardtime(secs) Message-ID: Feature Requests item #414029, was opened at 2001-04-05 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Neal Norwitz (nnorwitz) Summary: Request for time.standardtime(secs) Initial Comment: The time.localtime(secs) function always sets the dst flag to 1 and applies daylight savings time for that time zone. There isn't an easy way to get 'standard' time. A time.standardtime(secs) function would not apply the daylight savings time correction, set the dst flag to 0 (or -1?), but would correct for time zone difference from UTC. thanks tim cera ---------------------------------------------------------------------- >Comment By: Tim Cera (timcera) Date: 2002-12-21 13:29 Message: Logged In: YES user_id=169213 My initial comment/request is really uninformative. :-( I didn't even include which version of Python! For my job, we collect data time stamped with what we call 'Eastern Standard Time' which has the time zone correction of time.localtime, without the daylight savings time adjustment. The EST term may not be appropriate, but that is what we refer to our time stamps on our data. I am a little bit better at Python than when I asked for this function. What was once impossible or onerous has become trivial. So... >>> def standardtime(time_secs_int): ... import time ... return time.gmtime(time_secs_int - time.timezone) >>> import time >>> dst = time.mktime((2002, 6, 1, 0, 0, 0, 0, 0, 0)) >>> time.localtime(dst) (2002, 6, 1, 1, 0, 0, 5, 152, 1) >>> standardtime(dst) (2002, 6, 1, 0, 0, 0, 5, 152, 0) Definitely close this request. Eagerly waiting to see the new Date and Time classes in 2.3. thanks tim cera ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-17 08:22 Message: Logged In: YES user_id=33168 Tim Cera, I will close this in about a month unless you can provide clarification. I believe there may have been some issues with the DST flag in earlier versions of Python. However, these have been fixed. Also, with the new Date & Time classes Tim has added for Python 2.3, these should provide the functionality you want. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-16 23:26 Message: Logged In: YES user_id=31435 Unassigned this. I don't know what Tim Cera is asking for, so I suggest we close this unless clarification is forthcoming. >>> import time >>> time.localtime(time.time()) (2002, 12, 16, 23, 21, 36, 0, 350, 0) >>> _.tm_isdst 0 >>> That is, it's not true that time.localtime() always sets tm_isdst to 1, nor is it true that it always applies a DST adjustment. Perhaps he has a platform bug, but we don't know which platform, or version of Python, he's talking about. On top of all that, I've no idea what "standard time" means in this context. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:11 Message: Logged In: YES user_id=33168 Tim (Peters), here's another date/time one. This seems to already work for time.gmtime() which returns 0 for tm_isdst. Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 From noreply@sourceforge.net Sat Dec 21 22:25:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 14:25:03 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414029 ] Request for time.standardtime(secs) Message-ID: Feature Requests item #414029, was opened at 2001-04-05 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 Category: Extension Modules Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Neal Norwitz (nnorwitz) Summary: Request for time.standardtime(secs) Initial Comment: The time.localtime(secs) function always sets the dst flag to 1 and applies daylight savings time for that time zone. There isn't an easy way to get 'standard' time. A time.standardtime(secs) function would not apply the daylight savings time correction, set the dst flag to 0 (or -1?), but would correct for time zone difference from UTC. thanks tim cera ---------------------------------------------------------------------- Comment By: Tim Cera (timcera) Date: 2002-12-21 13:29 Message: Logged In: YES user_id=169213 My initial comment/request is really uninformative. :-( I didn't even include which version of Python! For my job, we collect data time stamped with what we call 'Eastern Standard Time' which has the time zone correction of time.localtime, without the daylight savings time adjustment. The EST term may not be appropriate, but that is what we refer to our time stamps on our data. I am a little bit better at Python than when I asked for this function. What was once impossible or onerous has become trivial. So... >>> def standardtime(time_secs_int): ... import time ... return time.gmtime(time_secs_int - time.timezone) >>> import time >>> dst = time.mktime((2002, 6, 1, 0, 0, 0, 0, 0, 0)) >>> time.localtime(dst) (2002, 6, 1, 1, 0, 0, 5, 152, 1) >>> standardtime(dst) (2002, 6, 1, 0, 0, 0, 5, 152, 0) Definitely close this request. Eagerly waiting to see the new Date and Time classes in 2.3. thanks tim cera ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-17 08:22 Message: Logged In: YES user_id=33168 Tim Cera, I will close this in about a month unless you can provide clarification. I believe there may have been some issues with the DST flag in earlier versions of Python. However, these have been fixed. Also, with the new Date & Time classes Tim has added for Python 2.3, these should provide the functionality you want. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-16 23:26 Message: Logged In: YES user_id=31435 Unassigned this. I don't know what Tim Cera is asking for, so I suggest we close this unless clarification is forthcoming. >>> import time >>> time.localtime(time.time()) (2002, 12, 16, 23, 21, 36, 0, 350, 0) >>> _.tm_isdst 0 >>> That is, it's not true that time.localtime() always sets tm_isdst to 1, nor is it true that it always applies a DST adjustment. Perhaps he has a platform bug, but we don't know which platform, or version of Python, he's talking about. On top of all that, I've no idea what "standard time" means in this context. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:11 Message: Logged In: YES user_id=33168 Tim (Peters), here's another date/time one. This seems to already work for time.gmtime() which returns 0 for tm_isdst. Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 From noreply@sourceforge.net Sun Dec 22 00:29:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 16:29:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-636685 ] ftplib bails out on empty responses Message-ID: Bugs item #636685, was opened at 2002-11-11 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib bails out on empty responses Initial Comment: In ftplib.py, FTP.getresp(), there is: if c in '123', and c is the first char of the reponse line. However, if the response is empty, then this line will throw an exception: File "/usr/lib/python2.2/ftplib.py", line 108, in __init__ self.connect(host) File "/usr/lib/python2.2/ftplib.py", line 133, in connect self.welcome = self.getresp() File "/usr/lib/python2.2/ftplib.py", line 216, in getresp if c not in '123': TypeError: 'in ' requires character as left operand System info: LinkChecker 1.6.6 Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 I suggest you test if c is a character before calling the if-clause. Cheers, Bastian ---------------------------------------------------------------------- >Comment By: Bastian Kleineidam (calvin) Date: 2002-12-22 01:29 Message: Logged In: YES user_id=9205 I got no more input from the user who reported this bug, so I am unable to reproduce it. Its ok for me to close this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 17:36 Message: Logged In: YES user_id=21627 I believe the assumption is guaranteed by the FTP protocol. I think we really need more information here. If you can come up with a tested patch (i.e. tested by your user, for this respective server), this might be sufficient to make a change - but I won't make a change without having understood all details of the change. If this is what it looks like (i.e. a protocol violation), error_proto would be appropriate. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-11-12 16:58 Message: Logged In: YES user_id=9205 I dont know which FTP server causes the exception, I already asked the submitter to provide more info. You can find the assorted bug report for this at http://sourceforge.net/tracker/index.php?func=detail&aid=635596&group_id=1913&atid=101913 Anyway, the ftplib code makes a non-guaranteed assumption about the response length. I think a solution would be to throw an ftplib error in case of an empty response. Cheers, Bastian ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:22 Message: Logged In: YES user_id=21627 Can you please explain in what case the server is supposed to send an empty response? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 From noreply@sourceforge.net Sun Dec 22 02:58:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 18:58:32 -0800 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: Neil Schemenauer (nascheme) 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: Neil Schemenauer (nascheme) Date: 2002-12-22 02:58 Message: Logged In: YES user_id=35752 The attached patch fixes the orignal bug reported along with a number of other related bugs. The patch does two things. First, it rearranges the code in abstract.c so that sq_repeat, sq_inplace_repeat, sq_concat and sq_inplace_concat are always called after trying the nb_* slots. The code before the patch was inconsistent about this and that caused the reported bug as well as others. The patch also consolidates the int and long sequence repeat code. Before the change, integers checked for overflow but longs did not. The consolidated code removes duplication and gets rid of some ugly code in intobject.c and longobject.c. The bug related to type.__mul__ has not been fixed. I'll open a new bug for it rather than reusing this one. Guido, I think this solves all the issues I dicussed with you a while back on the phone. It's amazing what you can get done on a long, cross country flight. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 20:00 Message: Logged In: YES user_id=6380 Sounds about right -- time to clise this issue? Note that the sq_repeat slot takes a C int, which somewhat limits what you can do with it, but that doesn't feel like a big problem. Can you figure out why 'a'.__mul__(3.5) does what it does? That seems like a bug to me. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 19:54 Message: Logged In: YES user_id=35752 Well, perhaps we cannot (eventually) get rid of sq_repeat. I actually quite like the way things work now. Just to refresh your memory in case it's fuzzy, the __mul__ method of integer like objects check for sq_repeat on the other object. If it exists then it calls it with itself as the "count" argument. Sequences don't implement nb_mul or return NotImplemented. So, the "protocol" has two parts. Sequence types expose a sq_repeat slot and integer types have a nb_mul that checks for sq_repeat. It's unclear to me what a __mul__ method on a sequence could do. What types of integer arguments should it accept? Allowing only ints and longs seems wrong to me. It should be possible for a extension type to work as well. I just noticed that the type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] To make it cosistent with the current modus operandi it should call __mul__ on the argument: >>> (3).__mul__('a') 'aaa' >>> (3.3).__mul__('a') NotImplemented ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 18:04 Message: Logged In: YES user_id=6380 Haven't looked at the patch, but I find that unacceptable. "%d" is sort of acceptable (although I wish it would round); there are a few other places where floats are accidentally accepted, but all of those are mistakes and we shouldn't add any more of those. Now what? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:32 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:29 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-10-25 21:27 Message: Logged In: YES user_id=35752 I got a bit worried when test_select failed after adding tp_as_number to the str object. It was triggered by select.select([], [], [], 'not a string'). The source of the problem was (hope this comes out okay): else if (!PyNumber_Check(tout)) { PyErr_SetString(PyExc_TypeError, "timeout must be a float or None"); return NULL; } else { tout = PyNumber_Float(tout); if (!tout) return NULL; The test was expecting TypeError but getting ValueError. I guess PyNumber_Check is pretty useless. Luckily it is only used in the select and operator modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-17 18: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 Sun Dec 22 03:00:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 19:00:39 -0800 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? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-22 02:58 Message: Logged In: YES user_id=35752 The attached patch fixes the orignal bug reported along with a number of other related bugs. The patch does two things. First, it rearranges the code in abstract.c so that sq_repeat, sq_inplace_repeat, sq_concat and sq_inplace_concat are always called after trying the nb_* slots. The code before the patch was inconsistent about this and that caused the reported bug as well as others. The patch also consolidates the int and long sequence repeat code. Before the change, integers checked for overflow but longs did not. The consolidated code removes duplication and gets rid of some ugly code in intobject.c and longobject.c. The bug related to type.__mul__ has not been fixed. I'll open a new bug for it rather than reusing this one. Guido, I think this solves all the issues I dicussed with you a while back on the phone. It's amazing what you can get done on a long, cross country flight. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 20:00 Message: Logged In: YES user_id=6380 Sounds about right -- time to clise this issue? Note that the sq_repeat slot takes a C int, which somewhat limits what you can do with it, but that doesn't feel like a big problem. Can you figure out why 'a'.__mul__(3.5) does what it does? That seems like a bug to me. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 19:54 Message: Logged In: YES user_id=35752 Well, perhaps we cannot (eventually) get rid of sq_repeat. I actually quite like the way things work now. Just to refresh your memory in case it's fuzzy, the __mul__ method of integer like objects check for sq_repeat on the other object. If it exists then it calls it with itself as the "count" argument. Sequences don't implement nb_mul or return NotImplemented. So, the "protocol" has two parts. Sequence types expose a sq_repeat slot and integer types have a nb_mul that checks for sq_repeat. It's unclear to me what a __mul__ method on a sequence could do. What types of integer arguments should it accept? Allowing only ints and longs seems wrong to me. It should be possible for a extension type to work as well. I just noticed that the type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] To make it cosistent with the current modus operandi it should call __mul__ on the argument: >>> (3).__mul__('a') 'aaa' >>> (3.3).__mul__('a') NotImplemented ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 18:04 Message: Logged In: YES user_id=6380 Haven't looked at the patch, but I find that unacceptable. "%d" is sort of acceptable (although I wish it would round); there are a few other places where floats are accidentally accepted, but all of those are mistakes and we shouldn't add any more of those. Now what? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:32 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:29 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-10-25 21:27 Message: Logged In: YES user_id=35752 I got a bit worried when test_select failed after adding tp_as_number to the str object. It was triggered by select.select([], [], [], 'not a string'). The source of the problem was (hope this comes out okay): else if (!PyNumber_Check(tout)) { PyErr_SetString(PyExc_TypeError, "timeout must be a float or None"); return NULL; } else { tout = PyNumber_Float(tout); if (!tout) return NULL; The test was expecting TypeError but getting ValueError. I guess PyNumber_Check is pretty useless. Luckily it is only used in the select and operator modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-17 18: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 Sun Dec 22 06:23:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Dec 2002 22:23:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-636685 ] ftplib bails out on empty responses Message-ID: Bugs item #636685, was opened at 2002-11-11 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib bails out on empty responses Initial Comment: In ftplib.py, FTP.getresp(), there is: if c in '123', and c is the first char of the reponse line. However, if the response is empty, then this line will throw an exception: File "/usr/lib/python2.2/ftplib.py", line 108, in __init__ self.connect(host) File "/usr/lib/python2.2/ftplib.py", line 133, in connect self.welcome = self.getresp() File "/usr/lib/python2.2/ftplib.py", line 216, in getresp if c not in '123': TypeError: 'in ' requires character as left operand System info: LinkChecker 1.6.6 Python 2.2.2 (#4, Oct 15 2002, 04:21:28) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 I suggest you test if c is a character before calling the if-clause. Cheers, Bastian ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-12-22 01:29 Message: Logged In: YES user_id=9205 I got no more input from the user who reported this bug, so I am unable to reproduce it. Its ok for me to close this bug. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 17:36 Message: Logged In: YES user_id=21627 I believe the assumption is guaranteed by the FTP protocol. I think we really need more information here. If you can come up with a tested patch (i.e. tested by your user, for this respective server), this might be sufficient to make a change - but I won't make a change without having understood all details of the change. If this is what it looks like (i.e. a protocol violation), error_proto would be appropriate. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2002-11-12 16:58 Message: Logged In: YES user_id=9205 I dont know which FTP server causes the exception, I already asked the submitter to provide more info. You can find the assorted bug report for this at http://sourceforge.net/tracker/index.php?func=detail&aid=635596&group_id=1913&atid=101913 Anyway, the ftplib code makes a non-guaranteed assumption about the response length. I think a solution would be to throw an ftplib error in case of an empty response. Cheers, Bastian ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-12 16:22 Message: Logged In: YES user_id=21627 Can you please explain in what case the server is supposed to send an empty response? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=636685&group_id=5470 From noreply@sourceforge.net Sun Dec 22 12:19:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Dec 2002 04:19:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-657469 ] Determining timed-out on Condition wait Message-ID: Bugs item #657469, was opened at 2002-12-22 13:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657469&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Determining timed-out on Condition wait Initial Comment: threading.Condition.wait currently does not report whether the condition was triggered, or whether a timeout occurred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657469&group_id=5470 From noreply@sourceforge.net Sun Dec 22 17:21:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Dec 2002 09:21:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-657469 ] Determining timed-out on Condition wait Message-ID: Bugs item #657469, was opened at 2002-12-22 07:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657469&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Determining timed-out on Condition wait Initial Comment: threading.Condition.wait currently does not report whether the condition was triggered, or whether a timeout occurred. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-22 12:21 Message: Logged In: YES user_id=31435 Martin, why do you consider this to be a bug? Proper use of the condition *protocol* requires checking whether the state you're wating for actually obtains after a wait() returns, and looping back to try again if the state doesn't obtain. The invariant promised by the condition protocol is simply that the condition is acquired whenever wait() returns (for whatever reason, be it signal, timeout, KeyboardInterrupt, SystemExit, ...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657469&group_id=5470 From noreply@sourceforge.net Sun Dec 22 21:15:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Dec 2002 13:15:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-657469 ] Determining timed-out on Condition wait Message-ID: Bugs item #657469, was opened at 2002-12-22 13:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657469&group_id=5470 Category: None >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Determining timed-out on Condition wait Initial Comment: threading.Condition.wait currently does not report whether the condition was triggered, or whether a timeout occurred. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-22 22:15 Message: Logged In: YES user_id=21627 Somebody suggested that this would be desirable; I now see it is not. Closing as not-a-bug. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-22 18:21 Message: Logged In: YES user_id=31435 Martin, why do you consider this to be a bug? Proper use of the condition *protocol* requires checking whether the state you're wating for actually obtains after a wait() returns, and looping back to try again if the state doesn't obtain. The invariant promised by the condition protocol is simply that the condition is acquired whenever wait() returns (for whatever reason, be it signal, timeout, KeyboardInterrupt, SystemExit, ...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657469&group_id=5470 From noreply@sourceforge.net Sun Dec 22 22:27:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Dec 2002 14:27:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-657625 ] nismodule gives a compiletime warning Message-ID: Bugs item #657625, was opened at 2002-12-22 23:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657625&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 2 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: nismodule gives a compiletime warning Initial Comment: Nismodule gives a compile time warning on MacOSX. It has a typedef of a foreachfunc with the signature typedef int (*foreachfunc)(int, char *, int, char *, int, char *); but the corresponding item to which this function is assigned (from ypcInt.h) has signature int (*foreach) __P((u_long, char *, int, char *, int, void *)); Someone with more understanding of NIS will have to fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657625&group_id=5470 From noreply@sourceforge.net Mon Dec 23 03:17:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Dec 2002 19:17:35 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-414029 ] Request for time.standardtime(secs) Message-ID: Feature Requests item #414029, was opened at 2001-04-05 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 Category: Extension Modules Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Neal Norwitz (nnorwitz) Summary: Request for time.standardtime(secs) Initial Comment: The time.localtime(secs) function always sets the dst flag to 1 and applies daylight savings time for that time zone. There isn't an easy way to get 'standard' time. A time.standardtime(secs) function would not apply the daylight savings time correction, set the dst flag to 0 (or -1?), but would correct for time zone difference from UTC. thanks tim cera ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-22 22:17 Message: Logged In: YES user_id=31435 Ah, so your vision of time for EST is always 5 hours west of UTC, regardless of DST. The new datetime module supplies a framework for dealing with time adjustments via so- called "tzinfo classes", but doesn't supply any concrete tzinfo classes. You can easily define your own, though, with any rules you like. For example, class EST(datetime.tzinfo): def utcoffset(self, dt): return -300 # minutes def tzname(self, dt): return "EST" A Python implementation of the module can be found in Python's CVS nondist/sandbox/datetime, and in Zope3's CVS lib/python/datetime. The C implemenation is in Python's CVS HEAD. So if you're *really* motivated , there are 3 ways to play with it now. ---------------------------------------------------------------------- Comment By: Tim Cera (timcera) Date: 2002-12-21 13:29 Message: Logged In: YES user_id=169213 My initial comment/request is really uninformative. :-( I didn't even include which version of Python! For my job, we collect data time stamped with what we call 'Eastern Standard Time' which has the time zone correction of time.localtime, without the daylight savings time adjustment. The EST term may not be appropriate, but that is what we refer to our time stamps on our data. I am a little bit better at Python than when I asked for this function. What was once impossible or onerous has become trivial. So... >>> def standardtime(time_secs_int): ... import time ... return time.gmtime(time_secs_int - time.timezone) >>> import time >>> dst = time.mktime((2002, 6, 1, 0, 0, 0, 0, 0, 0)) >>> time.localtime(dst) (2002, 6, 1, 1, 0, 0, 5, 152, 1) >>> standardtime(dst) (2002, 6, 1, 0, 0, 0, 5, 152, 0) Definitely close this request. Eagerly waiting to see the new Date and Time classes in 2.3. thanks tim cera ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-17 08:22 Message: Logged In: YES user_id=33168 Tim Cera, I will close this in about a month unless you can provide clarification. I believe there may have been some issues with the DST flag in earlier versions of Python. However, these have been fixed. Also, with the new Date & Time classes Tim has added for Python 2.3, these should provide the functionality you want. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-16 23:26 Message: Logged In: YES user_id=31435 Unassigned this. I don't know what Tim Cera is asking for, so I suggest we close this unless clarification is forthcoming. >>> import time >>> time.localtime(time.time()) (2002, 12, 16, 23, 21, 36, 0, 350, 0) >>> _.tm_isdst 0 >>> That is, it's not true that time.localtime() always sets tm_isdst to 1, nor is it true that it always applies a DST adjustment. Perhaps he has a platform bug, but we don't know which platform, or version of Python, he's talking about. On top of all that, I've no idea what "standard time" means in this context. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-16 23:11 Message: Logged In: YES user_id=33168 Tim (Peters), here's another date/time one. This seems to already work for time.gmtime() which returns 0 for tm_isdst. Can this be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414029&group_id=5470 From noreply@sourceforge.net Mon Dec 23 22:11:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Dec 2002 14:11:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-657625 ] nismodule gives a compiletime warning Message-ID: Bugs item #657625, was opened at 2002-12-22 23:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657625&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 2 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: nismodule gives a compiletime warning Initial Comment: Nismodule gives a compile time warning on MacOSX. It has a typedef of a foreachfunc with the signature typedef int (*foreachfunc)(int, char *, int, char *, int, char *); but the corresponding item to which this function is assigned (from ypcInt.h) has signature int (*foreach) __P((u_long, char *, int, char *, int, void *)); Someone with more understanding of NIS will have to fix this. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-23 23:11 Message: Logged In: YES user_id=21627 I would say this is a bug in your header file. There is, historically, no symbolic typedef for the foreach function, but the officially documented prototype (i.e. the on of the Sun documentation) uses an int argument. Nearly all other systems follow this specification; see #633013 for the most recent verification of this detail (for Tru64). I would discourage a change that specifically checks for OS X. If you think this needs to be fixed, please design an autoconf test to check for the argument of the foreach function; to implement such a test, you might need to convert the warning to an error, which might in turn mean that the test can only be executed for gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657625&group_id=5470 From noreply@sourceforge.net Mon Dec 23 22:35:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Dec 2002 14:35:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-658023 ] "What's New in 2.3", s12, verbatim error Message-ID: Bugs item #658023, was opened at 2002-12-23 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658023&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dyck (jmdyck) Assigned to: Nobody/Anonymous (nobody) Summary: "What's New in 2.3", s12, verbatim error Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html ("What's New in Python 2.3", section 12, "New and Improved Modules") The UserDict item has an unterminated 'verbatim' section (because '\end {verbatim}' has a space before the open brace?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658023&group_id=5470 From noreply@sourceforge.net Mon Dec 23 22:51:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Dec 2002 14:51:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-657625 ] nismodule gives a compiletime warning Message-ID: Bugs item #657625, was opened at 2002-12-22 23:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657625&group_id=5470 Category: Extension Modules >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 2 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: nismodule gives a compiletime warning Initial Comment: Nismodule gives a compile time warning on MacOSX. It has a typedef of a foreachfunc with the signature typedef int (*foreachfunc)(int, char *, int, char *, int, char *); but the corresponding item to which this function is assigned (from ypcInt.h) has signature int (*foreach) __P((u_long, char *, int, char *, int, void *)); Someone with more understanding of NIS will have to fix this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-12-23 23:51 Message: Logged In: YES user_id=45365 Ok, I'll leave it then. A configure check for a measly warning is too much work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-23 23:11 Message: Logged In: YES user_id=21627 I would say this is a bug in your header file. There is, historically, no symbolic typedef for the foreach function, but the officially documented prototype (i.e. the on of the Sun documentation) uses an int argument. Nearly all other systems follow this specification; see #633013 for the most recent verification of this detail (for Tru64). I would discourage a change that specifically checks for OS X. If you think this needs to be fixed, please design an autoconf test to check for the argument of the foreach function; to implement such a test, you might need to convert the warning to an error, which might in turn mean that the test can only be executed for gcc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=657625&group_id=5470 From noreply@sourceforge.net Tue Dec 24 01:02:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Dec 2002 17:02:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-658059 ] tempnam and tmpnam no longer in os Message-ID: Bugs item #658059, was opened at 2002-12-23 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658059&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: tempnam and tmpnam no longer in os Initial Comment: I'm assuming there's some autoconf changes which are causing this. No time to look at this now. I'll do it later, unless someone else fixes the problem. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658059&group_id=5470 From noreply@sourceforge.net Tue Dec 24 04:16:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Dec 2002 20:16:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-658106 ] Setting __class__ to NoneType Message-ID: Bugs item #658106, was opened at 2002-12-23 23:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Setting __class__ to NoneType Initial Comment: Creating an instance, setting its __class__ attribute to NoneType, and then allowing that instance to be garbage collected crashes the interpreter with an "Aborted" message. Example: >>> o = object() >>> o.__class__ = type(None) >>> del o Aborted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 From noreply@sourceforge.net Tue Dec 24 14:48:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 06:48:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-658106 ] Setting __class__ to NoneType Message-ID: Bugs item #658106, was opened at 2002-12-24 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Setting __class__ to NoneType Initial Comment: Creating an instance, setting its __class__ attribute to NoneType, and then allowing that instance to be garbage collected crashes the interpreter with an "Aborted" message. Example: >>> o = object() >>> o.__class__ = type(None) >>> del o Aborted ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-24 14:48 Message: Logged In: YES user_id=6656 This seems to be fixed on the trunk but still broken on the release22-maint branch. I'll dig, but not when I'm stuck behind a modem, so I won't be offended if someone beats me to it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 From noreply@sourceforge.net Tue Dec 24 14:49:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 06:49:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-658106 ] Setting __class__ to NoneType Message-ID: Bugs item #658106, was opened at 2002-12-23 23:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Neal Norwitz (nnorwitz) Summary: Setting __class__ to NoneType Initial Comment: Creating an instance, setting its __class__ attribute to NoneType, and then allowing that instance to be garbage collected crashes the interpreter with an "Aborted" message. Example: >>> o = object() >>> o.__class__ = type(None) >>> del o Aborted ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 09:49 Message: Logged In: YES user_id=33168 Thanks! Checked in Objects/typeobject.c 2.126.4.30 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-24 09:48 Message: Logged In: YES user_id=6656 This seems to be fixed on the trunk but still broken on the release22-maint branch. I'll dig, but not when I'm stuck behind a modem, so I won't be offended if someone beats me to it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 From noreply@sourceforge.net Tue Dec 24 14:51:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 06:51:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-658023 ] "What's New in 2.3", s12, verbatim error Message-ID: Bugs item #658023, was opened at 2002-12-23 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658023&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Dyck (jmdyck) >Assigned to: Neal Norwitz (nnorwitz) >Summary: "What's New in 2.3", s12, verbatim error Initial Comment: http://www.python.org/dev/doc/devel/whatsnew/node13.html ("What's New in Python 2.3", section 12, "New and Improved Modules") The UserDict item has an unterminated 'verbatim' section (because '\end {verbatim}' has a space before the open brace?). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 09:51 Message: Logged In: YES user_id=33168 Thanks, checked in whatsnew23.tex 1.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658023&group_id=5470 From noreply@sourceforge.net Tue Dec 24 14:54:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 06:54:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-658106 ] Setting __class__ to NoneType Message-ID: Bugs item #658106, was opened at 2002-12-24 04:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: Setting __class__ to NoneType Initial Comment: Creating an instance, setting its __class__ attribute to NoneType, and then allowing that instance to be garbage collected crashes the interpreter with an "Aborted" message. Example: >>> o = object() >>> o.__class__ = type(None) >>> del o Aborted ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-24 14:54 Message: Logged In: YES user_id=6656 Now *that's* a response time :) You didn't add a test, though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 14:49 Message: Logged In: YES user_id=33168 Thanks! Checked in Objects/typeobject.c 2.126.4.30 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-24 14:48 Message: Logged In: YES user_id=6656 This seems to be fixed on the trunk but still broken on the release22-maint branch. I'll dig, but not when I'm stuck behind a modem, so I won't be offended if someone beats me to it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 From noreply@sourceforge.net Tue Dec 24 15:13:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 07:13:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-658106 ] Setting __class__ to NoneType Message-ID: Bugs item #658106, was opened at 2002-12-23 23:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: Setting __class__ to NoneType Initial Comment: Creating an instance, setting its __class__ attribute to NoneType, and then allowing that instance to be garbage collected crashes the interpreter with an "Aborted" message. Example: >>> o = object() >>> o.__class__ = type(None) >>> del o Aborted ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 10:13 Message: Logged In: YES user_id=33168 Funny timing! I looked for a test in the current code (by grep) and didn't see any. You are right, of course. I'll add a test. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-24 09:54 Message: Logged In: YES user_id=6656 Now *that's* a response time :) You didn't add a test, though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 09:49 Message: Logged In: YES user_id=33168 Thanks! Checked in Objects/typeobject.c 2.126.4.30 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-24 09:48 Message: Logged In: YES user_id=6656 This seems to be fixed on the trunk but still broken on the release22-maint branch. I'll dig, but not when I'm stuck behind a modem, so I won't be offended if someone beats me to it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 From noreply@sourceforge.net Tue Dec 24 15:45:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 07:45:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-658233 ] gettext.py crash on bogus preamble Message-ID: Bugs item #658233, was opened at 2002-12-24 10:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658233&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: gettext.py crash on bogus preamble Initial Comment: If a .po file has the following bogus preamble: msgid "" msgstr "" "Project-Id-Version: Mailman 2.1b6\n" "POT-Creation-Date: Wed Dec 11 07:44:15 2002\n" "PO-Revision-Date: 2002-08-14 01:18:58+00:00\n" "Last-Translator: Ousmane Wilane \n" "Pascal George \n" "Language-Team: fr \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=iso-8859-15\n" "Content-Transfer-Encoding: quoted-printable\n" "Generated-By: pygettext.py 1.3\n" (notice that Last-Translator has an unexpected second line) then the resulting .mo file will crash Python when a translation is looked up. I got the following exception: Traceback (most recent call last): File "bin/update", line 48, in ? from Mailman import MailList File "/usr/local/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Archiver import Archiver File "/usr/local/mailman/Mailman/Archiver/__init__.py", line 17, in ? from Archiver import * File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 36, in ? from Mailman.i18n import _ File "/usr/local/mailman/Mailman/i18n.py", line 52, in ? set_language() File "/usr/local/mailman/Mailman/i18n.py", line 35, in set_language language) File "/usr/lib/python2.1/gettext.py", line 245, in translation t = _translations.setdefault(key, class_(open(mofile, 'rb'))) File "/usr/lib/python2.1/gettext.py", line 106, in __init__ self._parse(fp) File "/usr/lib/python2.1/gettext.py", line 180, in _parse k, v = item.split(':', 1) ValueError: unpack list of wrong size make: *** [update] Erreur 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658233&group_id=5470 From noreply@sourceforge.net Tue Dec 24 16:58:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 08:58:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-658254 ] Accept None for time.ctime() and friends Message-ID: Bugs item #658254, was opened at 2002-12-24 11:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Accept None for time.ctime() and friends Initial Comment: Several functions in the time module can have the time value they operate on omitted to indicate the current time, but they do not accept None as equivalent to omitting the value. It should be equivalent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470 From noreply@sourceforge.net Tue Dec 24 21:06:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Dec 2002 13:06:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-658106 ] Setting __class__ to NoneType Message-ID: Bugs item #658106, was opened at 2002-12-23 23:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: Setting __class__ to NoneType Initial Comment: Creating an instance, setting its __class__ attribute to NoneType, and then allowing that instance to be garbage collected crashes the interpreter with an "Aborted" message. Example: >>> o = object() >>> o.__class__ = type(None) >>> del o Aborted ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2002-12-24 16:06 Message: Logged In: YES user_id=366566 Awesome, thanks guys :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 10:13 Message: Logged In: YES user_id=33168 Funny timing! I looked for a test in the current code (by grep) and didn't see any. You are right, of course. I'll add a test. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-24 09:54 Message: Logged In: YES user_id=6656 Now *that's* a response time :) You didn't add a test, though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-24 09:49 Message: Logged In: YES user_id=33168 Thanks! Checked in Objects/typeobject.c 2.126.4.30 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-24 09:48 Message: Logged In: YES user_id=6656 This seems to be fixed on the trunk but still broken on the release22-maint branch. I'll dig, but not when I'm stuck behind a modem, so I won't be offended if someone beats me to it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658106&group_id=5470 From noreply@sourceforge.net Thu Dec 26 15:00:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 07:00:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-26 10:00 Message: Logged In: YES user_id=11375 A much simpler change is to modify the original patch that caused the problem, and strip the directory prefixes when python_build is true, trusting that there won't be conflicting filenames in the Python distribution. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 13:13 Message: Logged In: YES user_id=11375 Now I get it. In an in-tree build, the source path is something relative, such as ../Modules/foo.c, but in an out-of-tree build it's absolute. This is due to a line in setup.py, but I can't remember why this is done. One fix that's an egregious hack is to modify CCompiler.object_filenames: if strip_dir is false and the path is absolute, strip off the path to the source directory; see the attached patch. The patch also modifies setup.py to leave the path names alone. I'll keep thinking about this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 10:18 Message: Logged In: YES user_id=6656 OK, they don't actually break, but .o files end up in src/Modules/ rather than src/build-temp/build/temp.foo/ so multiple oot builds don't so what you'd expect. This came up on python-dev in the thread "extension module .o files wind up in the wrong place" starting here: http://mail.python.org/pipermail/python-dev/2002-December/030644.html ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 10:12 Message: Logged In: YES user_id=11375 One "make distclean" later, out-of-the-tree builds work fine for me. How do they fail? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 09:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 08:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Thu Dec 26 15:16:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 07:16:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-613222 ] memory leaks when importing posix module Message-ID: Bugs item #613222, was opened at 2002-09-23 10:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leaks when importing posix module Initial Comment: The attached program which calls Py_Initialize/Py_Finalize in a loop demonstrates a program which grows quite quickly. This bug effects 2.2.1+ and 2.3. valgrind reports that the memory is still reachable, but it seems like a memory leak and the process definitely grows. Compile the program with libpython, and run (./mem-test 100000). Make sure it can import site (which imports posix module). While the program is running, do a ps and watch it grow. If import site fails, the process will not grow. site.py can be as simple as import posix. I believe the problem is related to PyStructSequence_Fields for statfs. But haven't completely diagnosed the problem. As I learn more, I will add comments. To simply importing or not importing site, mem-test takes an optional 2nd argument which will enable/disable loading of site.py. ./mem-test 100000 1 will prevent import site. I hope this is understandable, even though the description wasn't clear. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-26 10:16 Message: Logged In: YES user_id=6380 I expect I will have no time to look into this further any time soon. But if you have fixes that clearly fix leaks, please check them in! (Shouldn't this be in the 2.3 group?) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-24 20:37 Message: Logged In: YES user_id=33168 I'm mostly stuck. I haven't solved the problem, but I do have some more information. Attached is a patch to Object/structseq.c which fixes some problems if memory allocation fails. Also, I changed a PyInt_FromLong(1) to Py_True for __safe_for_unpickling__. Py_True could also be used in compile.c:: symtable_load_symbols replacing the variable: implicit. Some fields which I believe are leaking from the PyTypeObject are: tp_members, tp_dict, and tp_bases. However, there are more leaks. I think all the remaining leaks come from PyType_Ready(). For example, from add_operators(), PyDescr_NewWrapper(). I thought DECREFing tp_dict would free these, but it didn't seem to have any effect. Part of the problem is how should these values be cleaned up. Putting cleanup in PyStructSequence_InitType would guarantee the problem is fixed for all structseqs, but that doesn't seem like a good idea. This would assume the PyTypeObject passed in is initialized. This is true for static variables, but not for any other variables. If there's a new API for cleanup, all the users of structseq will need to use it. Perhaps, this is only an issue in the core. I don't know about extension modules. Finally, I suspect there may be more leaks outside of posix too. These seem to mostly come from _Py_ReadyTypes() called in pythonrun.c::Py_Initialize(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-23 12:32 Message: Logged In: YES user_id=6380 This is a good use of your time. Thanks for looking into this! Assign back to me when you have a fix for review or a stumbling block. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470 From noreply@sourceforge.net Thu Dec 26 15:23:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 07:23:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-658693 ] cPickle does relative import Message-ID: Bugs item #658693, was opened at 2002-12-26 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658693&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle does relative import Initial Comment: save_global() in cPickle calls PyImport_ImportModule() to import the module of a global that's about to be pickled, in order to check whether the given name in fact refers to the given object. But when it is invoked from code living inside a package, PyImport_ImportModule() first tries a relative import, and if by sheer accident that relative import succeeds, it performs the wrong test. Example: in a package that has a submodule "exceptions", pickling instances of built-in exceptions will attempt to look up the exception class name in the exceptions submodule rather than in the built-in toplevel module by that name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658693&group_id=5470 From noreply@sourceforge.net Thu Dec 26 16:30:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 08:30:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-658059 ] tempnam and tmpnam no longer in os Message-ID: Bugs item #658059, was opened at 2002-12-23 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658059&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: tempnam and tmpnam no longer in os Initial Comment: I'm assuming there's some autoconf changes which are causing this. No time to look at this now. I'll do it later, unless someone else fixes the problem. :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 11:30 Message: Logged In: YES user_id=33168 Not sure what the problem was, but it's gone now. I suspect the changes Martin made to configure fixed the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658059&group_id=5470 From noreply@sourceforge.net Thu Dec 26 18:25:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 10:25:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-658749 ] asyncore connect() and winsock errors Message-ID: Bugs item #658749, was opened at 2002-12-26 13:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore connect() and winsock errors Initial Comment: asyncore's connect() method should interpret the winsock errors; these are different from Unix (and different between the Win98 family and the Win2k family). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&group_id=5470 From noreply@sourceforge.net Thu Dec 26 20:37:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 12:37:00 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-230359 ] Run script should not appear in shell window Message-ID: Feature Requests item #230359, was opened at 2001-01-28 18:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=230359&group_id=5470 >Category: IDLE Group: None Status: Open >Resolution: Remind Priority: 2 Submitted By: Martin v. Löwis (loewis) >Assigned to: Neal Norwitz (nnorwitz) Summary: Run script should not appear in shell window Initial Comment: When selecting "Run module" in the shell window, an error message "The buffer Python Shell is not saved..." is produced. Since running the shell window will fail in any case, these menu items should be removed from the shell window. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 15:37 Message: Logged In: YES user_id=33168 Reminder to close once IDLEfork is merged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 15:06 Message: Logged In: YES user_id=6380 Good suggestion. A revamping of the entire IDLE "run program" interface is planned, but won't be ready in time for 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=230359&group_id=5470 From noreply@sourceforge.net Thu Dec 26 20:37:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 12:37:46 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-229840 ] IDLE needs to print ! Message-ID: Feature Requests item #229840, was opened at 2001-01-23 13:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=229840&group_id=5470 Category: IDLE Group: None Status: Open >Resolution: Remind Priority: 1 Submitted By: Charles Doutriaux (cdoutri) >Assigned to: Neal Norwitz (nnorwitz) Summary: IDLE needs to print ! Initial Comment: It'd be really nice if idle had a print function, all these nice colors got to be printed ! or at least a postscript output would be nice. Thanks, C. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 15:37 Message: Logged In: YES user_id=33168 Reminder to close once IDLEfork is merged. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-10 12:46 Message: Logged In: YES user_id=31435 Changed Category to IDLE. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-23 21:40 Message: The kind folks from reportlab.com once contributed a printing function. it was kind of slow though. But maybe it should still be added. I think I have it somewhere still. The problem is the licensing (it's not relesed under the same license as Python itself). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=229840&group_id=5470 From noreply@sourceforge.net Thu Dec 26 21:05:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Dec 2002 13:05:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-26 21:05 Message: Logged In: YES user_id=6656 That would do, yes. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-26 15:00 Message: Logged In: YES user_id=11375 A much simpler change is to modify the original patch that caused the problem, and strip the directory prefixes when python_build is true, trusting that there won't be conflicting filenames in the Python distribution. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 18:13 Message: Logged In: YES user_id=11375 Now I get it. In an in-tree build, the source path is something relative, such as ../Modules/foo.c, but in an out-of-tree build it's absolute. This is due to a line in setup.py, but I can't remember why this is done. One fix that's an egregious hack is to modify CCompiler.object_filenames: if strip_dir is false and the path is absolute, strip off the path to the source directory; see the attached patch. The patch also modifies setup.py to leave the path names alone. I'll keep thinking about this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 15:18 Message: Logged In: YES user_id=6656 OK, they don't actually break, but .o files end up in src/Modules/ rather than src/build-temp/build/temp.foo/ so multiple oot builds don't so what you'd expect. This came up on python-dev in the thread "extension module .o files wind up in the wrong place" starting here: http://mail.python.org/pipermail/python-dev/2002-December/030644.html ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 15:12 Message: Logged In: YES user_id=11375 One "make distclean" later, out-of-the-tree builds work fine for me. How do they fail? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 14:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 13:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-14 01:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 21:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 21:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 21:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 21:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 15:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 15:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 20:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 20:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Fri Dec 27 23:13:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Dec 2002 15:13:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-659188 ] no docs for HTMLParser.handle_pi Message-ID: Bugs item #659188, was opened at 2002-12-28 00:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Arild Fines (arildfines) Assigned to: Nobody/Anonymous (nobody) Summary: no docs for HTMLParser.handle_pi Initial Comment: The current documentation(2.2.2) has no documentation for the handle_pi(handle processing instruction) method in the HTMLParser.HTMLParser class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470 From noreply@sourceforge.net Sat Dec 28 01:51:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Dec 2002 17:51:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-659228 ] 'realpath' function missing from os.path Message-ID: Bugs item #659228, was opened at 2002-12-27 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Nobody/Anonymous (nobody) Summary: 'realpath' function missing from os.path Initial Comment: The 'realpath()' function does not appear when you import all functions: from os.path import * Looks like this due to the name 'realpath' being missing from the '__all__' list in .../Python-2.2.2/Lib/posixpath.py All the other functions appear normally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 From noreply@sourceforge.net Sun Dec 29 06:00:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Dec 2002 22:00:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-645777 ] .extend() doc, .__doc__ too restrictive Message-ID: Bugs item #645777, was opened at 2002-11-29 12:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645777&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Raymond Hettinger (rhettinger) Summary: .extend() doc, .__doc__ too restrictive Initial Comment: LibRef 2.2.6.4 Mutable Sequence Types footnote (2) (current version)to S.extend(x) says "Raises an exception when x is not a list object." Similarly, >>> a.extend.__doc__ 'L.extend(list) -- extend list by appending list elements' However, x need only be iterable. For instance (2.2.1) >>> a.extend('ab') >>> a [1, 2, 3, 'a', 'b'] >> from __future__ import generators >>> def f(n): ... for i in range(n): yield i ... >>> a.extend(f(3)) >>> a [1, 2, 3, 'a', 'b', 0, 1, 2] Error message has already been updated: >>> a.extend(1) Traceback (most recent call last): File "", line 1, in ? TypeError: list.extend() argument must be iterable Question: footnote 2 also says "The extend() method is experimental". Still true after two additional releases, or time to delete this? The continuation "and not supported by mutable sequence types other than lists. " seems rather moot (and delete-able) unless and until another m.s.t is added. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-12-29 01:00 Message: Logged In: YES user_id=80475 Fixed. See listobject.c revision: 2.143 and 2.103.6.5. and libstdtypes.tex revision: 1.115 and 1.80.6.17. Closing bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645777&group_id=5470 From noreply@sourceforge.net Sun Dec 29 07:37:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 28 Dec 2002 23:37:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-659604 ] optparse store_true uses 1 and 0 Message-ID: Bugs item #659604, was opened at 2002-12-29 07:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) Assigned to: Nobody/Anonymous (nobody) Summary: optparse store_true uses 1 and 0 Initial Comment: When using store_true and store_false actions, the optparse module sets the values to 1 and 0, rather than True and False. --- optparse.py 14 Nov 2002 22:00:19 -0000 1.1 +++ optparse.py 29 Dec 2002 07:34:06 -0000 @@ -609,9 +609,9 @@ elif action == "store_const": setattr(values, dest, self.const) elif action == "store_true": - setattr(values, dest, 1) + setattr(values, dest, True) elif action == "store_false": - setattr(values, dest, 0) + setattr(values, dest, False) elif action == "append": values.ensure_value(dest, []).append(value) elif action == "count": ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470 From noreply@sourceforge.net Sun Dec 29 15:09:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Dec 2002 07:09:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-659604 ] optparse store_true uses 1 and 0 Message-ID: Bugs item #659604, was opened at 2002-12-29 02:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Lenihan (brianl) >Assigned to: Greg Ward (gward) Summary: optparse store_true uses 1 and 0 Initial Comment: When using store_true and store_false actions, the optparse module sets the values to 1 and 0, rather than True and False. --- optparse.py 14 Nov 2002 22:00:19 -0000 1.1 +++ optparse.py 29 Dec 2002 07:34:06 -0000 @@ -609,9 +609,9 @@ elif action == "store_const": setattr(values, dest, self.const) elif action == "store_true": - setattr(values, dest, 1) + setattr(values, dest, True) elif action == "store_false": - setattr(values, dest, 0) + setattr(values, dest, False) elif action == "append": values.ensure_value(dest, []).append(value) elif action == "count": ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-29 10:09 Message: Logged In: YES user_id=33168 Greg, any problem with making this change? Assign to me, if you want me to do it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659604&group_id=5470 From noreply@sourceforge.net Sun Dec 29 16:19:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Dec 2002 08:19:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-659709 ] bogus computation of float length Message-ID: Bugs item #659709, was opened at 2002-12-29 17:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659709&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: bogus computation of float length Initial Comment: The computation introduced in rev 2.70 of stringobject.c:formatfloat is bogus. If the expression "%.86f" % 999999999999999963589629496524800.00001 is computed, then the test whether this is smaller than 1e50 will succeed, so it continues to be printed as a float. However, the result has 33 digits before the decimal point, and 86 digits after the decimal point, so the entire result will need 121 bytes, more than the 120 bytes of buffer available. See Debian bug 172531 for how this crashes Python 2.1; for Python 2.2, it won't crash as the snprintf protects the buffer. However, the result is still incorrect: since the buffer is to small to represent 86 digits after the decimal point, an exception should be raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659709&group_id=5470 From noreply@sourceforge.net Sun Dec 29 17:55:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Dec 2002 09:55:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-01 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Ben Laurie (benl) Date: 2002-12-29 17:55 Message: Logged In: YES user_id=14333 BSD Version is ancient: 3.2-STABLE ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-03 01:27 Message: Logged In: YES user_id=250749 What FreeBSD version is this on? (I assume the reference to "current CVS" means Python's CVS head). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 13:28 Message: Logged In: YES user_id=14333 This test was run against the current CVS. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 06:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Sun Dec 29 18:18:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Dec 2002 10:18:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-599248 ] ext module generation problem Message-ID: Bugs item #599248, was opened at 2002-08-23 10:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 Category: Distutils Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: A.M. Kuchling (akuchling) Summary: ext module generation problem Initial Comment: when compiling an extension module, the source file location is not mirrored into the object file location, i.e. subdirectories are ignored (foo/bar/baz.c is compiled to baz.o, not foo/bar/baz.o) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-29 13:18 Message: Logged In: YES user_id=11375 Checked in. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-26 16:05 Message: Logged In: YES user_id=6656 That would do, yes. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-26 10:00 Message: Logged In: YES user_id=11375 A much simpler change is to modify the original patch that caused the problem, and strip the directory prefixes when python_build is true, trusting that there won't be conflicting filenames in the Python distribution. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 13:13 Message: Logged In: YES user_id=11375 Now I get it. In an in-tree build, the source path is something relative, such as ../Modules/foo.c, but in an out-of-tree build it's absolute. This is due to a line in setup.py, but I can't remember why this is done. One fix that's an egregious hack is to modify CCompiler.object_filenames: if strip_dir is false and the path is absolute, strip off the path to the source directory; see the attached patch. The patch also modifies setup.py to leave the path names alone. I'll keep thinking about this. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 10:18 Message: Logged In: YES user_id=6656 OK, they don't actually break, but .o files end up in src/Modules/ rather than src/build-temp/build/temp.foo/ so multiple oot builds don't so what you'd expect. This came up on python-dev in the thread "extension module .o files wind up in the wrong place" starting here: http://mail.python.org/pipermail/python-dev/2002-December/030644.html ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 10:12 Message: Logged In: YES user_id=11375 One "make distclean" later, out-of-the-tree builds work fine for me. How do they fail? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-04 09:54 Message: Logged In: YES user_id=11375 Not sure. I'm trying to replicate it, but current CVS out-of-tree builds are failing much earlier for me, when it tries to link Parser/pgen. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-04 08:27 Message: Logged In: YES user_id=6656 This broke out-of-tree builds of Python. Any quick ideas on what to do? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 20:30 Message: Logged In: YES user_id=11375 Great! Checked in as rev 1.52 of ccompiler.py, and I'll backport it to the 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=764 I 'applied' the patch to my python2.2 installation, i.e. I replaced the (single) call to 'object_filenames' by your version. That works. Thanks ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:47 Message: Logged In: YES user_id=11375 OK, then try the attached patch. Does it fix the problem? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-13 16:42 Message: Logged In: YES user_id=764 yes, precisely ! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 16:38 Message: Logged In: YES user_id=11375 Hm. Compiling my cryptography modules, it mirrors the location for the final source file (Crypto/Cipher/DES.so), but not for the intermediate .o file, which gets written to build/temp.linux-i686-2.3/DES.o. Is that the problem you're seeing? (In any case, the temp. directory should use full paths, so this is a bug.) ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-11-06 10:21 Message: Logged In: YES user_id=764 I experienced it with linux / gcc ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 10:14 Message: Logged In: YES user_id=11375 Hm, this is supposed to work, judging by the docstring of Compiler.compile(). Maybe some subclass of Compiler gets it wrong; what platform are you on? ---------------------------------------------------------------------- Comment By: Stefan Seefeld (stefan) Date: 2002-08-23 15:31 Message: Logged In: YES user_id=764 precisely. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-23 15:26 Message: Logged In: YES user_id=3066 Why is this a problem? Are you running into name clashes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=599248&group_id=5470 From noreply@sourceforge.net Sun Dec 29 19:44:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Dec 2002 11:44:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-659709 ] bogus computation of float length Message-ID: Bugs item #659709, was opened at 2002-12-29 17:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659709&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: bogus computation of float length Initial Comment: The computation introduced in rev 2.70 of stringobject.c:formatfloat is bogus. If the expression "%.86f" % 999999999999999963589629496524800.00001 is computed, then the test whether this is smaller than 1e50 will succeed, so it continues to be printed as a float. However, the result has 33 digits before the decimal point, and 86 digits after the decimal point, so the entire result will need 121 bytes, more than the 120 bytes of buffer available. See Debian bug 172531 for how this crashes Python 2.1; for Python 2.2, it won't crash as the snprintf protects the buffer. However, the result is still incorrect: since the buffer is to small to represent 86 digits after the decimal point, an exception should be raised. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-12-29 20:44 Message: Logged In: YES user_id=38388 Fix checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659709&group_id=5470 From noreply@sourceforge.net Mon Dec 30 15:47:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 07:47:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-660022 ] parameters for int(), str(), etc. Message-ID: Bugs item #660022, was opened at 2002-12-30 07:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Nobody/Anonymous (nobody) Summary: parameters for int(), str(), etc. Initial Comment: The built-in functions int(), str(), float(), long() are documented as requiring a parameter, but the type/class unification has changed them so that they return a false object without a parameter: >>> int() 0 >>> str() '' >>> float() 0.0 >>> long() 0L ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 From noreply@sourceforge.net Mon Dec 30 15:28:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 07:28:00 -0800 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: Neal Norwitz (nnorwitz) 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: Neil Schemenauer (nascheme) Date: 2002-12-30 15:28 Message: Logged In: YES user_id=35752 This should probably get in before the alpha release. Guido appears to be busy. Feel free to reassign if you don't have time. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-22 02:58 Message: Logged In: YES user_id=35752 The attached patch fixes the orignal bug reported along with a number of other related bugs. The patch does two things. First, it rearranges the code in abstract.c so that sq_repeat, sq_inplace_repeat, sq_concat and sq_inplace_concat are always called after trying the nb_* slots. The code before the patch was inconsistent about this and that caused the reported bug as well as others. The patch also consolidates the int and long sequence repeat code. Before the change, integers checked for overflow but longs did not. The consolidated code removes duplication and gets rid of some ugly code in intobject.c and longobject.c. The bug related to type.__mul__ has not been fixed. I'll open a new bug for it rather than reusing this one. Guido, I think this solves all the issues I dicussed with you a while back on the phone. It's amazing what you can get done on a long, cross country flight. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 20:00 Message: Logged In: YES user_id=6380 Sounds about right -- time to clise this issue? Note that the sq_repeat slot takes a C int, which somewhat limits what you can do with it, but that doesn't feel like a big problem. Can you figure out why 'a'.__mul__(3.5) does what it does? That seems like a bug to me. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 19:54 Message: Logged In: YES user_id=35752 Well, perhaps we cannot (eventually) get rid of sq_repeat. I actually quite like the way things work now. Just to refresh your memory in case it's fuzzy, the __mul__ method of integer like objects check for sq_repeat on the other object. If it exists then it calls it with itself as the "count" argument. Sequences don't implement nb_mul or return NotImplemented. So, the "protocol" has two parts. Sequence types expose a sq_repeat slot and integer types have a nb_mul that checks for sq_repeat. It's unclear to me what a __mul__ method on a sequence could do. What types of integer arguments should it accept? Allowing only ints and longs seems wrong to me. It should be possible for a extension type to work as well. I just noticed that the type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] To make it cosistent with the current modus operandi it should call __mul__ on the argument: >>> (3).__mul__('a') 'aaa' >>> (3.3).__mul__('a') NotImplemented ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 18:04 Message: Logged In: YES user_id=6380 Haven't looked at the patch, but I find that unacceptable. "%d" is sort of acceptable (although I wish it would round); there are a few other places where floats are accidentally accepted, but all of those are mistakes and we shouldn't add any more of those. Now what? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:32 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:29 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-10-25 21:27 Message: Logged In: YES user_id=35752 I got a bit worried when test_select failed after adding tp_as_number to the str object. It was triggered by select.select([], [], [], 'not a string'). The source of the problem was (hope this comes out okay): else if (!PyNumber_Check(tout)) { PyErr_SetString(PyExc_TypeError, "timeout must be a float or None"); return NULL; } else { tout = PyNumber_Float(tout); if (!tout) return NULL; The test was expecting TypeError but getting ValueError. I guess PyNumber_Check is pretty useless. Luckily it is only used in the select and operator modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-17 18: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 Mon Dec 30 15:50:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 07:50:10 -0800 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: Neal Norwitz (nnorwitz) 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-12-30 10:50 Message: Logged In: YES user_id=6380 I'll look at it right now. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-30 10:28 Message: Logged In: YES user_id=35752 This should probably get in before the alpha release. Guido appears to be busy. Feel free to reassign if you don't have time. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-21 21:58 Message: Logged In: YES user_id=35752 The attached patch fixes the orignal bug reported along with a number of other related bugs. The patch does two things. First, it rearranges the code in abstract.c so that sq_repeat, sq_inplace_repeat, sq_concat and sq_inplace_concat are always called after trying the nb_* slots. The code before the patch was inconsistent about this and that caused the reported bug as well as others. The patch also consolidates the int and long sequence repeat code. Before the change, integers checked for overflow but longs did not. The consolidated code removes duplication and gets rid of some ugly code in intobject.c and longobject.c. The bug related to type.__mul__ has not been fixed. I'll open a new bug for it rather than reusing this one. Guido, I think this solves all the issues I dicussed with you a while back on the phone. It's amazing what you can get done on a long, cross country flight. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 15:00 Message: Logged In: YES user_id=6380 Sounds about right -- time to clise this issue? Note that the sq_repeat slot takes a C int, which somewhat limits what you can do with it, but that doesn't feel like a big problem. Can you figure out why 'a'.__mul__(3.5) does what it does? That seems like a bug to me. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 14:54 Message: Logged In: YES user_id=35752 Well, perhaps we cannot (eventually) get rid of sq_repeat. I actually quite like the way things work now. Just to refresh your memory in case it's fuzzy, the __mul__ method of integer like objects check for sq_repeat on the other object. If it exists then it calls it with itself as the "count" argument. Sequences don't implement nb_mul or return NotImplemented. So, the "protocol" has two parts. Sequence types expose a sq_repeat slot and integer types have a nb_mul that checks for sq_repeat. It's unclear to me what a __mul__ method on a sequence could do. What types of integer arguments should it accept? Allowing only ints and longs seems wrong to me. It should be possible for a extension type to work as well. I just noticed that the type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] To make it cosistent with the current modus operandi it should call __mul__ on the argument: >>> (3).__mul__('a') 'aaa' >>> (3.3).__mul__('a') NotImplemented ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 13:04 Message: Logged In: YES user_id=6380 Haven't looked at the patch, but I find that unacceptable. "%d" is sort of acceptable (although I wish it would round); there are a few other places where floats are accidentally accepted, but all of those are mistakes and we shouldn't add any more of those. Now what? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 11:32 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 11:29 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-10-25 17:27 Message: Logged In: YES user_id=35752 I got a bit worried when test_select failed after adding tp_as_number to the str object. It was triggered by select.select([], [], [], 'not a string'). The source of the problem was (hope this comes out okay): else if (!PyNumber_Check(tout)) { PyErr_SetString(PyExc_TypeError, "timeout must be a float or None"); return NULL; } else { tout = PyNumber_Float(tout); if (!tout) return NULL; The test was expecting TypeError but getting ValueError. I guess PyNumber_Check is pretty useless. Luckily it is only used in the select and operator modules. ---------------------------------------------------------------------- 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 Mon Dec 30 16:19:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 08:19:19 -0800 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: Neil Schemenauer (nascheme) 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-12-30 11:19 Message: Logged In: YES user_id=6380 This looks good. Neil, do you have time to commit the changes today? If not, reassign to me and I'll do it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 10:50 Message: Logged In: YES user_id=6380 I'll look at it right now. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-30 10:28 Message: Logged In: YES user_id=35752 This should probably get in before the alpha release. Guido appears to be busy. Feel free to reassign if you don't have time. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-21 21:58 Message: Logged In: YES user_id=35752 The attached patch fixes the orignal bug reported along with a number of other related bugs. The patch does two things. First, it rearranges the code in abstract.c so that sq_repeat, sq_inplace_repeat, sq_concat and sq_inplace_concat are always called after trying the nb_* slots. The code before the patch was inconsistent about this and that caused the reported bug as well as others. The patch also consolidates the int and long sequence repeat code. Before the change, integers checked for overflow but longs did not. The consolidated code removes duplication and gets rid of some ugly code in intobject.c and longobject.c. The bug related to type.__mul__ has not been fixed. I'll open a new bug for it rather than reusing this one. Guido, I think this solves all the issues I dicussed with you a while back on the phone. It's amazing what you can get done on a long, cross country flight. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 15:00 Message: Logged In: YES user_id=6380 Sounds about right -- time to clise this issue? Note that the sq_repeat slot takes a C int, which somewhat limits what you can do with it, but that doesn't feel like a big problem. Can you figure out why 'a'.__mul__(3.5) does what it does? That seems like a bug to me. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 14:54 Message: Logged In: YES user_id=35752 Well, perhaps we cannot (eventually) get rid of sq_repeat. I actually quite like the way things work now. Just to refresh your memory in case it's fuzzy, the __mul__ method of integer like objects check for sq_repeat on the other object. If it exists then it calls it with itself as the "count" argument. Sequences don't implement nb_mul or return NotImplemented. So, the "protocol" has two parts. Sequence types expose a sq_repeat slot and integer types have a nb_mul that checks for sq_repeat. It's unclear to me what a __mul__ method on a sequence could do. What types of integer arguments should it accept? Allowing only ints and longs seems wrong to me. It should be possible for a extension type to work as well. I just noticed that the type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] To make it cosistent with the current modus operandi it should call __mul__ on the argument: >>> (3).__mul__('a') 'aaa' >>> (3.3).__mul__('a') NotImplemented ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 13:04 Message: Logged In: YES user_id=6380 Haven't looked at the patch, but I find that unacceptable. "%d" is sort of acceptable (although I wish it would round); there are a few other places where floats are accidentally accepted, but all of those are mistakes and we shouldn't add any more of those. Now what? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 11:32 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 11:29 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-10-25 17:27 Message: Logged In: YES user_id=35752 I got a bit worried when test_select failed after adding tp_as_number to the str object. It was triggered by select.select([], [], [], 'not a string'). The source of the problem was (hope this comes out okay): else if (!PyNumber_Check(tout)) { PyErr_SetString(PyExc_TypeError, "timeout must be a float or None"); return NULL; } else { tout = PyNumber_Float(tout); if (!tout) return NULL; The test was expecting TypeError but getting ValueError. I guess PyNumber_Check is pretty useless. Luckily it is only used in the select and operator modules. ---------------------------------------------------------------------- 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 Mon Dec 30 17:19:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 09:19:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-552345 ] rfc822.parsedate() too strict Message-ID: Bugs item #552345, was opened at 2002-05-04 16:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552345&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.parsedate() too strict Initial Comment: rfc822.parsedate('Wed,3 Apr 2002 14:58:26 +0800') returns None. Note the lack of space between the command and the 3. That space is actually optional in RFC 2822, so it should parse the same as parsedate('Wed, 3 Apr 2002 14:58:26 +0800') ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 12:19 Message: Logged In: YES user_id=12800 I'm actually not interested in fixing this for rfc822.py, but I have a simpler patch for email.Utils._parseaddr, along with a test case. I'm going to check that in now. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-19 00:39 Message: Logged In: YES user_id=80475 Added a patch and unittest which fix the reported problem. Tried to adopt a style of accurate implementation that can be extended when we get a chance. The style is to use regular expressions which relate directly back to the rfc2822 specification. If approved, re-assign back to me for a commit to Py2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552345&group_id=5470 From noreply@sourceforge.net Mon Dec 30 17:29:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 09:29:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-654362 ] email: huge address lines blow stack Message-ID: Bugs item #654362, was opened at 2002-12-15 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654362&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: huge address lines blow stack Initial Comment: The following code will recurse until Python throws an exception: """ import email.Utils addrlist = ["foo@bar.com"] * 2000 email.Utils.getaddresses(addrlist) """ I found a huge address list in my spam archive, which is how I found the error. Attaching suggested patch that avoids recursion. bugfix candidate I guess? ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 12:29 Message: Logged In: YES user_id=12800 Funny, I just copied the implementation of this up from rfc822.py into _parseaddr.py and it has something very similar to what you done. It uses += instead of .extend() but I think that makes no difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654362&group_id=5470 From noreply@sourceforge.net Mon Dec 30 17:46:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 09:46:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-650441 ] email test external dependencies Message-ID: Bugs item #650441, was opened at 2002-12-08 10:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650441&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email test external dependencies Initial Comment: The email package test depends on audiotest.au which comes as part of Python's test suite. This can fail for standalone email on some systems that don't package the test suite with their "non-devel" Python packages. email/test/data should include a simple, small audio file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=650441&group_id=5470 From noreply@sourceforge.net Mon Dec 30 17:47:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 09:47:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-660083 ] GNU readline 4.2 prompt issue Message-ID: Bugs item #660083, was opened at 2002-12-30 12:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660083&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: GNU readline 4.2 prompt issue Initial Comment: When Python is linked with GNU readline 4.2, using raw_input() without a prompt causes the most recent non-empty prompt to be used. GNU readline 4.1 and before don't have this behavior. I don't want it, but I don't know how to disable it (I am passing an empty string for the prompt to readline()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660083&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:29:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:29:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-660095 ] GNU readline version confusion Message-ID: Bugs item #660095, was opened at 2002-12-30 13:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660095&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 3 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: GNU readline version confusion Initial Comment: configure and setup.py don't look for GNU readline the same way. If you have e.g. readline 4.2 installed in /usr and a different version in /usr/local, setup.py uses the version from /usr/local, but the feature testing in configure finds the 4.2 features in /usr/lib/libreadline* anyway. :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660095&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:33:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:33:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-648119 ] more email ASCII decoding errors Message-ID: Bugs item #648119, was opened at 2002-12-03 18:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: more email ASCII decoding errors Initial Comment: email package v2.4.3. A similar problem was reported and fixed in http://python.org/sf/621457 The problem is that when using the Header.Header class to create a header, and the header value contains non-ASCII data that can't be decoded, a UnicodeError is raised. This is a problem when using email to process SPAM (as I do in TMDA), as SPAM often does contain random non-ASCII data in its headers. Some way of handling these cases more gracefully, without provoking a UnicodeError is necessary. See the attached traceback.txt for an example. The tmda-mess.txt file referenced from traceback.txt is also attached in case you want to reproduce the problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 13:33 Message: Logged In: YES user_id=12800 Matthew's suggestion was to expose the `errors' argument to the unicode() builtin in Header.__init__() and .append(). I think that's the best we can do. I'll work out a patch for email 2.5 (Python 2.3a1). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:39:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:39:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:41:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:41:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:44:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:44:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:43:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:43:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-648119 ] more email ASCII decoding errors Message-ID: Bugs item #648119, was opened at 2002-12-03 18:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: more email ASCII decoding errors Initial Comment: email package v2.4.3. A similar problem was reported and fixed in http://python.org/sf/621457 The problem is that when using the Header.Header class to create a header, and the header value contains non-ASCII data that can't be decoded, a UnicodeError is raised. This is a problem when using email to process SPAM (as I do in TMDA), as SPAM often does contain random non-ASCII data in its headers. Some way of handling these cases more gracefully, without provoking a UnicodeError is necessary. See the attached traceback.txt for an example. The tmda-mess.txt file referenced from traceback.txt is also attached in case you want to reproduce the problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 13:43 Message: Logged In: YES user_id=12800 What do you think about this patch... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 13:33 Message: Logged In: YES user_id=12800 Matthew's suggestion was to expose the `errors' argument to the unicode() builtin in Header.__init__() and .append(). I think that's the best we can do. I'll work out a patch for email 2.5 (Python 2.3a1). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 From noreply@sourceforge.net Mon Dec 30 18:50:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 10:50:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-12-30 19:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 19:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Mon Dec 30 19:14:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 11:14:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-648119 ] more email ASCII decoding errors Message-ID: Bugs item #648119, was opened at 2002-12-03 18:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: more email ASCII decoding errors Initial Comment: email package v2.4.3. A similar problem was reported and fixed in http://python.org/sf/621457 The problem is that when using the Header.Header class to create a header, and the header value contains non-ASCII data that can't be decoded, a UnicodeError is raised. This is a problem when using email to process SPAM (as I do in TMDA), as SPAM often does contain random non-ASCII data in its headers. Some way of handling these cases more gracefully, without provoking a UnicodeError is necessary. See the attached traceback.txt for an example. The tmda-mess.txt file referenced from traceback.txt is also attached in case you want to reproduce the problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 14:14 Message: Logged In: YES user_id=12800 Applied ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 13:43 Message: Logged In: YES user_id=12800 What do you think about this patch... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 13:33 Message: Logged In: YES user_id=12800 Matthew's suggestion was to expose the `errors' argument to the unicode() builtin in Header.__init__() and .append(). I think that's the best we can do. I'll work out a patch for email 2.5 (Python 2.3a1). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=648119&group_id=5470 From noreply@sourceforge.net Mon Dec 30 19:26:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 11:26:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-629756 ] FAIL: test_crlf_separation (email.test.t Message-ID: Bugs item #629756, was opened at 2002-10-28 05:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FAIL: test_crlf_separation (email.test.t Initial Comment: just because text file on windows has CR/LF as endline maker and this test expects LF as eol. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 14:26 Message: Logged In: YES user_id=12800 It looks like you built this from source on Windows. If you unzip'd the source without turning off any dumb CRLF munging in your zip program, the test file will not be correct and this test will fail. Tim assures me that this test succeeds in Python 2.2 and 2.3a1 and I trust him with my lunch. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-10-29 06:28 Message: Logged In: YES user_id=115179 Python 2.2.2 from October 14, 2002, compiled from source on windows 2000 all expected test are passed but not test_email. reproducable by: pushd Lib\test ..\..\python regrtest.py popd -- or cd Lib\test ..\..\python test_email.py traceback: FAILED (failures=1) Traceback (most recent call last): File "test_email.py", line 13, in ? test_main() File "test_email.py", line 10, in test_main run_suite(suite()) File "c:\binw\py222\lib\test\test_support.py", line 175, in run_suite raise TestFailed(err) test_support.TestFailed: Traceback (most recent call last): File "c:\binw\py222\lib\email\test\test_email.py", line 1851, in test_crlf_sep aration eq(part1.get_payload(), 'Simple email with attachment.\r\n\r\n') File "c:\binw\py222\lib\unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Simple email with attachment.\n\n' != 'Simple email with attach ment.\r\n\r\n' after applying this patch thist test will pass --- test_email.py Mon Oct 14 17:26:03 2002 +++ test_email.py.new Tue Oct 29 11:25:54 2002 @@ -46,7 +46,7 @@ def openfile(filename): path = os.path.join(os.path.dirname(landmark), 'data', filename) - return open(path, 'r') + return open(path, 'rb') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-28 10:33 Message: Logged In: YES user_id=31435 Assigned to Barry. Grzegorz, please supply more detail, such as which version of Python you're using, and the commands you used to run this test. As the name of the test should imply ("test_crlf_....), the test *expects* CR/LF -- that's it's point. It passes for me under 2.2.2 and current CVS Python, under Win98SE and Win2K. It may not have passed in 2.2.1, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 From noreply@sourceforge.net Mon Dec 30 20:29:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 12:29:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 20:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Mon Dec 30 20:31:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 12:31:56 -0800 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) 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: Neil Schemenauer (nascheme) Date: 2002-12-30 20:31 Message: Logged In: YES user_id=35752 Checked in. See abstract.c 2.113 for the main change. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 16:19 Message: Logged In: YES user_id=6380 This looks good. Neil, do you have time to commit the changes today? If not, reassign to me and I'll do it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 15:50 Message: Logged In: YES user_id=6380 I'll look at it right now. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-30 15:28 Message: Logged In: YES user_id=35752 This should probably get in before the alpha release. Guido appears to be busy. Feel free to reassign if you don't have time. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-22 02:58 Message: Logged In: YES user_id=35752 The attached patch fixes the orignal bug reported along with a number of other related bugs. The patch does two things. First, it rearranges the code in abstract.c so that sq_repeat, sq_inplace_repeat, sq_concat and sq_inplace_concat are always called after trying the nb_* slots. The code before the patch was inconsistent about this and that caused the reported bug as well as others. The patch also consolidates the int and long sequence repeat code. Before the change, integers checked for overflow but longs did not. The consolidated code removes duplication and gets rid of some ugly code in intobject.c and longobject.c. The bug related to type.__mul__ has not been fixed. I'll open a new bug for it rather than reusing this one. Guido, I think this solves all the issues I dicussed with you a while back on the phone. It's amazing what you can get done on a long, cross country flight. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 20:00 Message: Logged In: YES user_id=6380 Sounds about right -- time to clise this issue? Note that the sq_repeat slot takes a C int, which somewhat limits what you can do with it, but that doesn't feel like a big problem. Can you figure out why 'a'.__mul__(3.5) does what it does? That seems like a bug to me. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 19:54 Message: Logged In: YES user_id=35752 Well, perhaps we cannot (eventually) get rid of sq_repeat. I actually quite like the way things work now. Just to refresh your memory in case it's fuzzy, the __mul__ method of integer like objects check for sq_repeat on the other object. If it exists then it calls it with itself as the "count" argument. Sequences don't implement nb_mul or return NotImplemented. So, the "protocol" has two parts. Sequence types expose a sq_repeat slot and integer types have a nb_mul that checks for sq_repeat. It's unclear to me what a __mul__ method on a sequence could do. What types of integer arguments should it accept? Allowing only ints and longs seems wrong to me. It should be possible for a extension type to work as well. I just noticed that the type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] To make it cosistent with the current modus operandi it should call __mul__ on the argument: >>> (3).__mul__('a') 'aaa' >>> (3.3).__mul__('a') NotImplemented ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-18 18:04 Message: Logged In: YES user_id=6380 Haven't looked at the patch, but I find that unacceptable. "%d" is sort of acceptable (although I wish it would round); there are a few other places where floats are accidentally accepted, but all of those are mistakes and we shouldn't add any more of those. Now what? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:32 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-11-18 16:29 Message: Logged In: YES user_id=35752 The attached patch adds nb_add and nb_mul slots to str and unicode. All tests pass after this change. One resulting behavior change is that: "ab" * 4.5 works like "ab" * 4 That's a little unsettling to me but I guess it's consistient with: "%d" % 4.5 Please review. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-10-25 21:27 Message: Logged In: YES user_id=35752 I got a bit worried when test_select failed after adding tp_as_number to the str object. It was triggered by select.select([], [], [], 'not a string'). The source of the problem was (hope this comes out okay): else if (!PyNumber_Check(tout)) { PyErr_SetString(PyExc_TypeError, "timeout must be a float or None"); return NULL; } else { tout = PyNumber_Float(tout); if (!tout) return NULL; The test was expecting TypeError but getting ValueError. I guess PyNumber_Check is pretty useless. Luckily it is only used in the select and operator modules. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-17 18: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 Mon Dec 30 21:15:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 13:15:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-660165 ] PyFile_GetLine() doesn't grok unicode Message-ID: Bugs item #660165, was opened at 2002-12-30 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PyFile_GetLine() doesn't grok unicode Initial Comment: PyFile_GetLine() complains when object.readline() returns a Unicode string. This is only used by raw_input() (and possible by 3rd party extensions). Could we change it to either allow Unicode strings, or at least attempt to convert the result to str()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 From noreply@sourceforge.net Mon Dec 30 22:45:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 14:45:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__ Message-ID: Bugs item #532767, was opened at 2002-03-20 17:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Steve Alexander (stevea_zope) Assigned to: Guido van Rossum (gvanrossum) Summary: isinstance() should respect __class__ Initial Comment: isinstance(obj, class_or_type_or_tuple) should compare using obj.__class__ when obj is an instance of a type or a new-style class. This is important for using weak references and other kinds of proxy wrappers, where you want to pass a proxy to some code, which might query its type using isinstance. issubclass may need a similar treatment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-21 09:52 Message: Logged In: YES user_id=6380 I'm not sure I like SteveA's suggestion of making isinstance() respond both to the wrapper type and to the wrapped type. Although there's a precedent: >>> class C: pass # classic class ... >>> c = C() >>> isinstance(c, C) 1 >>> import types >>> isinstance(c, types.InstanceType) 1 >>> I'm also not sure I agree with Martin's assertion that type(o) is X and isinstance(o, X) should always be equivalent. Especially with new-style user-defined classes, we could also require that o.__class__ == X and isinstance(o, X) should be equivalent (modulo subclassing), and that would require isinstance() to prefer __class__. I guess we'll have to look at actual use cases of isinstance() and wrappers (both weakrefs and Zope3's transparent wrappers). My expectation is that, since wrappers try hard to pretend to be the wrapped object, extending this to the isinstance() test is more useful than the stricter interpretation. ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2002-03-21 08:57 Message: Logged In: YES user_id=492001 oops... please ignore my unsupported use of "is" to compare small ints. I meant: from Zope.ContextWrapper import Wrapper wl = Wrapper([]) assert isinstance(wl, list) == 1 assert isinstance(wl, Wrapper) == 1 ---------------------------------------------------------------------- Comment By: Steve Alexander (stevea_zope) Date: 2002-03-21 08:55 Message: Logged In: YES user_id=492001 A new isinstance can maintain and extend the semantic Martin describes. Let's say object wl is a wrapped list: from Zope.ContextWrapper import Wrapper wl = Wrapper([]) assert isinstance(wl, list) is 1 assert isinstance(wl, Wrapper) is 1 So, your semantics are maintained. With the proposed change, the property you describe need not be given up. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-21 08:47 Message: Logged In: YES user_id=21627 There has been a long-standing guarantee that 'type(o) is X' implies 'isinstance(o, X)', or, more compact, 'isinstance(o,type(o))' for all objects o. In fact, people have been advised to change the explicit test for type() to isinstance calls. With the proposed change, this property will be given up. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-21 08:16 Message: Logged In: YES user_id=6380 I give this a +1. To refute Martin's -1: The use case that prompts this is passing a wrapper to wrapper-ignorant code. This may be 3rd party code that you can't afford to make wrapper-aware. If I pass you a wrapper to an X where you expect an X, your isinstance(x, X) call should succeed. Especially since x.__class__ already returns X. Also, isinstance(x, X) succeeds if X is a classic class and x is a wrapped X instance. If you want to know if something is a wrapper, you have to use type(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-21 03:59 Message: Logged In: YES user_id=21627 -1. That means that you can't use isinstance anymore to determine whether something is a weak reference, or other kind of proxy wrapper. If you need a function that unwraps wrappers, write one yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470 From noreply@sourceforge.net Mon Dec 30 22:45:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 14:45:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-642358 ] metaclass causes __dict__ to be dict Message-ID: Bugs item #642358, was opened at 2002-11-22 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: metaclass causes __dict__ to be dict Initial Comment: class Meta(type): def __new__(meta, name, bases, dict): return super(Meta, name).__new__(meta, name, bases, dict) class AClass: __metaclass__ = Meta print type(AClass.__dict__) With 2.2.2, this prints dict-proxy. With 2.3, this prints dict. As you noted, it should always be a dict-proxy to prevent people from getting the __dict__ and the tp slots out of sync. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 From noreply@sourceforge.net Mon Dec 30 22:47:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 14:47:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-595026 ] Support for masks in getargs.c Message-ID: Bugs item #595026, was opened at 2002-08-14 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Support for masks in getargs.c Initial Comment: We need this implemented: > How about the following counterproposal. This also changes some of > the other format codes to be a little more regular. > > Code C type Range check > > b unsigned char 0..UCHAR_MAX > B unsigned char none ** > h unsigned short 0..USHRT_MAX > H unsigned short none ** > i int INT_MIN..INT_MAX > I * unsigned int 0..UINT_MAX > l long LONG_MIN..LONG_MAX > k * unsigned long none > L long long LLONG_MIN..LLONG_MAX > K * unsigned long long none > > Notes: > > * New format codes. > > ** Changed from previous "range-and-a-half" to "none"; the > range-and-a-half checking wasn't particularly useful. Plus a C API or two, e.g. PyInt_AsLongMask() -> unsigned long and PyInt_AsLongLongMask() -> unsigned long long (if that exists). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595026&group_id=5470 From noreply@sourceforge.net Mon Dec 30 22:51:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 14:51:52 -0800 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: 6 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 Mon Dec 30 22:52:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 14:52:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply@sourceforge.net Mon Dec 30 23:05:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 15:05:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-660165 ] PyFile_GetLine() doesn't grok unicode Message-ID: Bugs item #660165, was opened at 2002-12-30 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PyFile_GetLine() doesn't grok unicode Initial Comment: PyFile_GetLine() complains when object.readline() returns a Unicode string. This is only used by raw_input() (and possible by 3rd party extensions). Could we change it to either allow Unicode strings, or at least attempt to convert the result to str()? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 00:05 Message: Logged In: YES user_id=21627 I'm in favour of allowing raw_input to return Unicode objects. This would follow the principle that you shall convert to a byte string at the latest possible point in processing (i.e. immediately before the byte-oriented storage). It may surprise applications, but it (in itself) isn't an incompatible change (as you now get an exception). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 From noreply@sourceforge.net Tue Dec 31 00:08:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 16:08:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-639945 ] 64-bit bug on AIX Message-ID: Bugs item #639945, was opened at 2002-11-18 03:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639945&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Florent Cayré (florent_cayre) Assigned to: Neal Norwitz (nnorwitz) Summary: 64-bit bug on AIX Initial Comment: A bug in dynload_aix.c causes unpredictable segmentation faults on 64-bit AIX when importing a module. This bug is due to an (unsigned int) improper cast in the aix_getoldmodules function, returning a bad address as the beginning of the next ld_info structure pointed to by ldiptr. Following is a minimalist patch proposal obtained by changing these (unsigned int) casts into (char*) casts in the Python 2.2.1 version. Regards, Florent Cayré. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:08 Message: Logged In: YES user_id=33168 Checked in as Python/dynload_aix.c 2.13. 2.3a1 should be out in about a day. Florent, it would be great if you can test it on both 32- and 64- bit AIX. Leaving open to remind to backport to 2.2.3 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-22 09:48 Message: Logged In: YES user_id=33168 Florent, thank you. Your patch seems correct, but unfortunately I can't test it at this time. Once I can test it, I will check in the changes. If someone else can verify this patch works for them on both 32 & 64 bit compiles, I will check it in. ---------------------------------------------------------------------- Comment By: Florent Cayré (florent_cayre) Date: 2002-11-20 01:59 Message: Logged In: YES user_id=648804 Not sure I understand your question... However I filled in the Group drop down list and join my entire dynload_aix.c file with the proposed correction in it. Regards, Florent Cayré. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-19 14:04 Message: Logged In: YES user_id=33168 Florent, could you please point out the exact code and change necessary? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639945&group_id=5470 From noreply@sourceforge.net Tue Dec 31 01:02:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Dec 2002 17:02:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-660165 ] PyFile_GetLine() doesn't grok unicode Message-ID: Bugs item #660165, was opened at 2002-12-30 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Martin v. Löwis (loewis) Summary: PyFile_GetLine() doesn't grok unicode Initial Comment: PyFile_GetLine() complains when object.readline() returns a Unicode string. This is only used by raw_input() (and possible by 3rd party extensions). Could we change it to either allow Unicode strings, or at least attempt to convert the result to str()? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 20:02 Message: Logged In: YES user_id=6380 Wanna cook up a patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-30 18:05 Message: Logged In: YES user_id=21627 I'm in favour of allowing raw_input to return Unicode objects. This would follow the principle that you shall convert to a byte string at the latest possible point in processing (i.e. immediately before the byte-oriented storage). It may surprise applications, but it (in itself) isn't an incompatible change (as you now get an exception). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 From noreply@sourceforge.net Tue Dec 31 11:51:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 03:51:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-02 05:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-31 22:51 Message: Logged In: YES user_id=250749 I can't replicate this failure on FreeBSD 4.4. I notice that the failure would appear to be in the pthreads library; have you tried building Python without thread support? ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-30 04:55 Message: Logged In: YES user_id=14333 BSD Version is ancient: 3.2-STABLE ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-03 12:27 Message: Logged In: YES user_id=250749 What FreeBSD version is this on? (I assume the reference to "current CVS" means Python's CVS head). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-03 00:28 Message: Logged In: YES user_id=14333 This test was run against the current CVS. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 17:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 10:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Tue Dec 31 12:59:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 04:59:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-597919 ] compiler package and SET_LINENO Message-ID: Bugs item #597919, was opened at 2002-08-20 20: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: 7 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Guido van Rossum (gvanrossum) 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-12-31 12:59 Message: Logged In: YES user_id=6656 Here's the patch I posted a link to python-dev yesterday. Assigning to Guido; he might actually do something about it :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-26 15:14 Message: Logged In: YES user_id=6656 Raising priority: something ABSOLUTELY HAS to be done about this before 2.3a1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 18:29 Message: Logged In: YES user_id=11375 I'd like to add my vote for bumping up the priority of this patch; two people have run into this so far. ---------------------------------------------------------------------- Comment By: Bill Noon (bnoon) Date: 2002-11-01 20:18 Message: Logged In: YES user_id=298547 I just used the patch to fix problems with Quixote. Seems to have done the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-10 10:38 Message: Logged In: YES user_id=6656 Ah good. Will wait for your comments. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-09 23: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 13: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 11: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 10: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 16: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 10: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 17: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 10: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 Tue Dec 31 13:12:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 05:12:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-651124 ] pydoc ignores $PAGER if TERM=='dumb' Message-ID: Bugs item #651124, was opened at 2002-12-09 17:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Ka-Ping Yee (ping) Summary: pydoc ignores $PAGER if TERM=='dumb' Initial Comment: bug: pydoc ignores $PAGER environment variable if TERM=='dumb' symptom: when using pydoc as a keyword helper system (set keywordprg) pydoc scrolls all over its contents without paging, since gvim sets its terminal type to 'dumb' for shell escape. Fix: patch included. function getpager() rearranged. Inyeol Lee ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 08:12 Message: Logged In: YES user_id=33168 Ping, do you agree with this patch? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2002-12-09 17:06 Message: Logged In: YES user_id=595280 description on symptom above is for gvim. it was not clear there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 From noreply@sourceforge.net Tue Dec 31 13:16:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 05:16:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-644345 ] Poor error message for augmented assign Message-ID: Bugs item #644345, was opened at 2002-11-26 16:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644345&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: Jeremy Hylton (jhylton) Summary: Poor error message for augmented assign Initial Comment: >>> [1,2] += [2,3] SyntaxError: augmented assign to list not possible A similar error message is generated when augmented assignment is used on tuple literals. This error message is desceptive because augmented assignment is allowed on both of those types. I would change the message to: SyntaxError: can't assign to literal I may generate a patch for this, but not anytime soon. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 08:16 Message: Logged In: YES user_id=33168 Jeremy, do you agree? How about adding the word literal to the error msg, so it reads: * augmented assign to literal list not possible ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644345&group_id=5470 From noreply@sourceforge.net Tue Dec 31 13:19:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 05:19:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter() Message-ID: Bugs item #639611, was opened at 2002-11-17 04:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) >Assigned to: Tim Peters (tim_one) Summary: crash (SEGV) in Py_EndInterpreter() Initial Comment: I experience a 80% reproducable SIGSEGV in a multithreaded app I wrote using different embedded sub interpreters in its threads. I have a C++ class (PClass) which encapsulates the sub-interpreters somehow - it creates a new one in its constructor and deletes it in the destructor (see below). When 2 objects of this class are destroyed at nearly the same time thus resulting in subsequent calls to Py_EndInterpreter() (but for the different threads), I get the following SIGSEGV in most cases: > gdb application core.31889 [...] Program terminated with signal 11, Segmentation fault. [...] Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 169 _PyObject_GC_UNTRACK(op); (gdb) bt #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 #1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at Python/pystate.c:190 #2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at Python/pystate.c:77 #3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at Python/pythonrun.c:381 #4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123 When the 2nd object is destroyed some seconds later, everything seems to be fine. It only crashes when the 2 objects are deleted within a short period of time. I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built Python-2.2.2 with the same result. :-( Here's a very short snippet of the python related code in my class: // Constructor, initializes Python sub-interpreter PClass::PClass() { PyEval_AcquireLock(); py_state=Py_NewInterpreter(); PyEval_SaveThread(); } // destructor, kills the Python sub-interpreter PClass::~PClass() { PyEval_RestoreThread(py_state); Py_EndInterpreter(py_state); py_state=NULL; PyEval_ReleaseLock(); // release lock } // thread code, runs Python function void PClass::run() { PyEval_RestoreThread(py_state); PyObject_CallFunction(...) PyEval_SaveThread(); } ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 08:19 Message: Logged In: YES user_id=33168 Tim, it was suggested you see this. Is this documented somewhere? What should be done? ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-21 04:31 Message: Logged In: YES user_id=115179 I think it should be documented and additional check performed before killing thread state or interpereter. Leave it open - Tim Peters should see this. ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-21 01:09 Message: Logged In: YES user_id=633130 Ok, after cleaning up my exception handling a little bit (especially preventing exceptions to be triggered from outside after run() has finished) I can't reproduce the problems any more. So the bug is worked around for me. I leave it open if you consider this to be a real bug which has to be fixed. If you don't fix it and an user must always call PyErr_Clear() before Py_EndInterpreter() this should be documented IMHO. TIA! ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-20 03:12 Message: Logged In: YES user_id=633130 It really seems to have some connection with my exception handling. I'm investigating further. Please stand by... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-18 09:00 Message: Logged In: YES user_id=115179 I have found it (perhaps), while an python exception is pending and PyEval_RestoreThread is called, my Python anwalys bumps. After adding PyErr_Clear or PyErr_Print just before this call makes python happy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 From noreply@sourceforge.net Tue Dec 31 15:39:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 07:39:10 -0800 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: 7 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Guido van Rossum (gvanrossum) 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-12-31 15:39 Message: Logged In: YES user_id=31392 Looks like a good patch. I'm running Tools/compiler/regrtest.py just in case. I'll check it in assuming that the tests pass. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-31 12:59 Message: Logged In: YES user_id=6656 Here's the patch I posted a link to python-dev yesterday. Assigning to Guido; he might actually do something about it :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-26 15:14 Message: Logged In: YES user_id=6656 Raising priority: something ABSOLUTELY HAS to be done about this before 2.3a1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 18:29 Message: Logged In: YES user_id=11375 I'd like to add my vote for bumping up the priority of this patch; two people have run into this so far. ---------------------------------------------------------------------- Comment By: Bill Noon (bnoon) Date: 2002-11-01 20:18 Message: Logged In: YES user_id=298547 I just used the patch to fix problems with Quixote. Seems to have done the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-10 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 Tue Dec 31 16:47:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 08:47:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-01 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Ben Laurie (benl) Date: 2002-12-31 16:47 Message: Logged In: YES user_id=14333 Indeed, it works OK with threads disabled. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-31 11:51 Message: Logged In: YES user_id=250749 I can't replicate this failure on FreeBSD 4.4. I notice that the failure would appear to be in the pthreads library; have you tried building Python without thread support? ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-29 17:55 Message: Logged In: YES user_id=14333 BSD Version is ancient: 3.2-STABLE ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-03 01:27 Message: Logged In: YES user_id=250749 What FreeBSD version is this on? (I assume the reference to "current CVS" means Python's CVS head). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 13:28 Message: Logged In: YES user_id=14333 This test was run against the current CVS. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 06:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Tue Dec 31 17:01:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 09:01:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-646547 ] test_poll fails on FreeBSD Message-ID: Bugs item #646547, was opened at 2002-12-01 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 Category: None >Group: 3rd Party >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 18:01 Message: Logged In: YES user_id=21627 I would then declare that threads are not supported on that platform; closing it as third-party. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-31 17:47 Message: Logged In: YES user_id=14333 Indeed, it works OK with threads disabled. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-31 12:51 Message: Logged In: YES user_id=250749 I can't replicate this failure on FreeBSD 4.4. I notice that the failure would appear to be in the pthreads library; have you tried building Python without thread support? ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-29 18:55 Message: Logged In: YES user_id=14333 BSD Version is ancient: 3.2-STABLE ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-03 02:27 Message: Logged In: YES user_id=250749 What FreeBSD version is this on? (I assume the reference to "current CVS" means Python's CVS head). ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 14:28 Message: Logged In: YES user_id=14333 This test was run against the current CVS. ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-12-02 07:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 00:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=646547&group_id=5470 From noreply@sourceforge.net Tue Dec 31 18:11:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 10:11:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Tue Dec 31 18:19:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 10:19:06 -0800 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: Closed >Resolution: Accepted Priority: 7 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-12-31 18:19 Message: Logged In: YES user_id=31392 Committed for the 2.3a1 release. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-12-31 15:39 Message: Logged In: YES user_id=31392 Looks like a good patch. I'm running Tools/compiler/regrtest.py just in case. I'll check it in assuming that the tests pass. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-31 12:59 Message: Logged In: YES user_id=6656 Here's the patch I posted a link to python-dev yesterday. Assigning to Guido; he might actually do something about it :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-26 15:14 Message: Logged In: YES user_id=6656 Raising priority: something ABSOLUTELY HAS to be done about this before 2.3a1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 18:29 Message: Logged In: YES user_id=11375 I'd like to add my vote for bumping up the priority of this patch; two people have run into this so far. ---------------------------------------------------------------------- Comment By: Bill Noon (bnoon) Date: 2002-11-01 20:18 Message: Logged In: YES user_id=298547 I just used the patch to fix problems with Quixote. Seems to have done the trick. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-10 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 Tue Dec 31 19:20:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 11:20:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:01:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:01:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Nobody/Anonymous (nobody) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:11:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:11:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Nobody/Anonymous (nobody) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 15:11 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:18:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:18:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Nobody/Anonymous (nobody) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- >Comment By: Paul Swartz (z3p) Date: 2002-12-31 15:18 Message: Logged In: YES user_id=123843 Yeah, that bites me every time I use SF. Trying again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 15:11 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:33:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:33:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2002-12-31 20:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:50:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:50:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-513033 ] unsafe call to PyThreadState_Swap Message-ID: Bugs item #513033, was opened at 2002-02-04 23:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470 Category: Python Library Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Jake McGuire (jamcguir) Assigned to: Guido van Rossum (gvanrossum) Summary: unsafe call to PyThreadState_Swap Initial Comment: It appears that there is a blatantly unsafe call to PyThreadState_Swap in the functions on_hook and on_completer in Modules/Readline.c The diff adding these calls is viewable at http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Modules/readline .c.diff?r1=2.5&r2=2.6&only_with_tag=MAIN The call to PyThreadState_Swap is added directly below a comment pointing out that readline() is called with the interpreter lock released. Viewing the code shows that the interpreter lock is indeed released before calling readline (in myreadline.c). Multithreaded programs that define callback functions suffer from intermittent crashes, often Py_FatalError- ing claiming "tstate mix-up" from ceval.c Removing the calls to PyThreadState_Swap makes these problems go away. Can someone explain how the call to PyThreadState_Swap is indeed the right thing to be doing? ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 20:50 Message: Logged In: YES user_id=670441 That PyThreadState_Swap sure looks wrong to me. The code before the diff you reference also looks wrong though. See my posting under bug 660476 for a fix. (My bug is the same as yours, but I didn't realize it when I posted it) ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2002-06-11 21:09 Message: Logged In: YES user_id=246063 Just wanted to note that this problem is affecting my users as well, I believe in the on_completion branch rather than the on_hook branch. We're using Python to write multi-threaded scientific applications; with other Python threads active, pressing TAB for interactive completion occasionally yields the tstate mix-up. We are perfectly happy to wait for Python 2.3 for a fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-18 03:15 Message: Logged In: YES user_id=6380 That's ancient history and will take some time to wrap my brains around. I don't have time for this tonight, maybe tomorrow but I doubt the priority can be raised enough to catch my attention long enough to matter. But it should be fixed for 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 17:40 Message: Logged In: YES user_id=6656 jamcguir (or indeed anyone else), can you provide a patch for this pronto? I'd kind of like to have it fixed in 2.2.1, but this is obscure enough that I'm not going to hold up the release for it. ---------------------------------------------------------------------- Comment By: Jake McGuire (jamcguir) Date: 2002-02-04 23:55 Message: Logged In: YES user_id=448911 Unfortunately, the scenario isn't really *simple*. I think it goes like this: Thread A defines a readline startup hook. Thread A calls PyOS_Readline() in myreadline.c Thread A calls Py_BEGIN_ALLOW_THREADS, saving its thread state and setting the global thread state to NULL. Thread A calls readline. Thread A gets blocked, and Thread B gets scheduled. Thread B grabs the global interpreter lock, and restores its thread state. Thread B gets suspended, and Thread A gets scheduled. -- note: Thread B has the intepreter lock -- Thread A calls PyThreadState_Swap in on_hook(), setting the current global thread state to NULL Thread A calls PyEval_RestoreThread, which blocks waiting for the global interpreter lock Thread B gets scheduled, tries to run, but finds that the global thread state is NULL. Bad things happen. Proposed solution: Change Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS in myreadline.c:PyOS_Readline to calls to PyEval_SaveThread and PyEval_RestoreThread. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-04 23:41 Message: Logged In: YES user_id=31435 Guido's checkin comment said: """ Darn. When thread support is disabled, the BEGIN/END macros don't save and restore the tstate, but explicitly calling PyEval_SaveThread() does reset it! While I think about how to fix this for real, here's a fix that avoids getting a fatal error. """ Therefore I assigned the bug to Guido . It would help if you could describe a specific simple scenario that provokes the problems you're seeing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:53:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:53:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 15:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Tue Dec 31 20:58:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 12:58:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None >Priority: 6 Submitted By: Michael Stone (mbrierst) >Assigned to: Guido van Rossum (gvanrossum) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 15:58 Message: Logged In: YES user_id=6380 Will look after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 15:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Tue Dec 31 21:06:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 13:06:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Nobody/Anonymous (nobody) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 16:06 Message: Logged In: YES user_id=33168 I believe the attached patch will fix the problem. Paul, can you confirm? ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2002-12-31 15:18 Message: Logged In: YES user_id=123843 Yeah, that bites me every time I use SF. Trying again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 15:11 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 From noreply@sourceforge.net Tue Dec 31 21:36:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 13:36:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) >Assigned to: Neal Norwitz (nnorwitz) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-12-31 12:36 Message: Logged In: YES user_id=86216 Yes, your patch is essentially the same as mine: https://sourceforge.net/tracker/? func=detail&aid=660522&group_id=5470&atid=305470 Please check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 12:06 Message: Logged In: YES user_id=33168 I believe the attached patch will fix the problem. Paul, can you confirm? ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2002-12-31 11:18 Message: Logged In: YES user_id=123843 Yeah, that bites me every time I use SF. Trying again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 11:11 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 From noreply@sourceforge.net Tue Dec 31 21:35:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 13:35:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-639611 ] crash (SEGV) in Py_EndInterpreter() Message-ID: Bugs item #639611, was opened at 2002-11-17 04:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) >Assigned to: Guido van Rossum (gvanrossum) Summary: crash (SEGV) in Py_EndInterpreter() Initial Comment: I experience a 80% reproducable SIGSEGV in a multithreaded app I wrote using different embedded sub interpreters in its threads. I have a C++ class (PClass) which encapsulates the sub-interpreters somehow - it creates a new one in its constructor and deletes it in the destructor (see below). When 2 objects of this class are destroyed at nearly the same time thus resulting in subsequent calls to Py_EndInterpreter() (but for the different threads), I get the following SIGSEGV in most cases: > gdb application core.31889 [...] Program terminated with signal 11, Segmentation fault. [...] Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/local/lib/python2.2/lib-dynload/time.so #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 169 _PyObject_GC_UNTRACK(op); (gdb) bt #0 0x08078763 in class_dealloc (op=0x81a8624) at Objects/classobject.c:169 #1 0x080daefa in PyThreadState_Clear (tstate=0x816b7f0) at Python/pystate.c:190 #2 0x080dab89 in PyInterpreterState_Clear (interp=0x81427e8) at Python/pystate.c:77 #3 0x080dce1e in Py_EndInterpreter (tstate=0x816b7f0) at Python/pythonrun.c:381 #4 0x0805c287 in ~PClass (this=0x81421d0) at pclass.cpp:123 When the 2nd object is destroyed some seconds later, everything seems to be fine. It only crashes when the 2 objects are deleted within a short period of time. I've tried this with the SuSE RPMs of Python 2.2.1 and a self-built Python-2.2.2 with the same result. :-( Here's a very short snippet of the python related code in my class: // Constructor, initializes Python sub-interpreter PClass::PClass() { PyEval_AcquireLock(); py_state=Py_NewInterpreter(); PyEval_SaveThread(); } // destructor, kills the Python sub-interpreter PClass::~PClass() { PyEval_RestoreThread(py_state); Py_EndInterpreter(py_state); py_state=NULL; PyEval_ReleaseLock(); // release lock } // thread code, runs Python function void PClass::run() { PyEval_RestoreThread(py_state); PyObject_CallFunction(...) PyEval_SaveThread(); } ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-31 16:35 Message: Logged In: YES user_id=31435 Guido should look at it -- subinterpreters were his idea . ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 08:19 Message: Logged In: YES user_id=33168 Tim, it was suggested you see this. Is this documented somewhere? What should be done? ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-21 04:31 Message: Logged In: YES user_id=115179 I think it should be documented and additional check performed before killing thread state or interpereter. Leave it open - Tim Peters should see this. ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-21 01:09 Message: Logged In: YES user_id=633130 Ok, after cleaning up my exception handling a little bit (especially preventing exceptions to be triggered from outside after run() has finished) I can't reproduce the problems any more. So the bug is worked around for me. I leave it open if you consider this to be a real bug which has to be fixed. If you don't fix it and an user must always call PyErr_Clear() before Py_EndInterpreter() this should be documented IMHO. TIA! ---------------------------------------------------------------------- Comment By: Gernot Hillier (yoda_gh) Date: 2002-11-20 03:12 Message: Logged In: YES user_id=633130 It really seems to have some connection with my exception handling. I'm investigating further. Please stand by... ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-11-18 09:00 Message: Logged In: YES user_id=115179 I have found it (perhaps), while an python exception is pending and PyEval_RestoreThread is called, my Python anwalys bumps. After adding PyErr_Clear or PyErr_Print just before this call makes python happy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639611&group_id=5470 From noreply@sourceforge.net Tue Dec 31 21:56:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 13:56:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Neal Norwitz (nnorwitz) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 16:56 Message: Logged In: YES user_id=33168 Checked in as Modules/_randommodule.c 1.2 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 16:36 Message: Logged In: YES user_id=86216 Yes, your patch is essentially the same as mine: https://sourceforge.net/tracker/? func=detail&aid=660522&group_id=5470&atid=305470 Please check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 16:06 Message: Logged In: YES user_id=33168 I believe the attached patch will fix the problem. Paul, can you confirm? ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2002-12-31 15:18 Message: Logged In: YES user_id=123843 Yeah, that bites me every time I use SF. Trying again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 15:11 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 From noreply@sourceforge.net Tue Dec 31 22:22:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Dec 2002 14:22:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-660492 ] compile of _randommodule.c fails on cygwin Message-ID: Bugs item #660492, was opened at 2002-12-31 15:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470 Category: Build Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Neal Norwitz (nnorwitz) Summary: compile of _randommodule.c fails on cygwin Initial Comment: Compilation of Modules/_randommodule.c fails with Python CVS. I attached the errors gcc raises. I'm using gcc 3.2 on Cygwin, DLL version 1.3.17. ---------------------------------------------------------------------- >Comment By: Paul Swartz (z3p) Date: 2002-12-31 17:22 Message: Logged In: YES user_id=123843 Yes, it works. Many thanks to both of you. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 16:56 Message: Logged In: YES user_id=33168 Checked in as Modules/_randommodule.c 1.2 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-31 16:36 Message: Logged In: YES user_id=86216 Yes, your patch is essentially the same as mine: https://sourceforge.net/tracker/? func=detail&aid=660522&group_id=5470&atid=305470 Please check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 16:06 Message: Logged In: YES user_id=33168 I believe the attached patch will fix the problem. Paul, can you confirm? ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2002-12-31 15:18 Message: Logged In: YES user_id=123843 Yeah, that bites me every time I use SF. Trying again. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-31 15:11 Message: Logged In: YES user_id=31435 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660492&group_id=5470